We have a single page application which we ship changes to on a regular basis. On rare occasion, a version of the client has a bug and submits a bad request to the server. Even after you ship out an update, there's a possibility old versions of the client can linger.
In these circumstances, it would be useful for the client to send a version identifier along with our requests so that we know whether which version of the code base initiated it.
Are there any existing best practices for this scenario? Attaching an extra header seems like a simple solution, but I don't want to tread new ground if this problem has already been addressed.
We have a single page application which we ship changes to on a regular basis. On rare occasion, a version of the client has a bug and submits a bad request to the server. Even after you ship out an update, there's a possibility old versions of the client can linger.
In these circumstances, it would be useful for the client to send a version identifier along with our requests so that we know whether which version of the code base initiated it.
Are there any existing best practices for this scenario? Attaching an extra header seems like a simple solution, but I don't want to tread new ground if this problem has already been addressed.
Share Improve this question asked Jul 5, 2013 at 14:55 Brad KochBrad Koch 20.3k20 gold badges112 silver badges140 bronze badges 3-
That's what
User-Agentis for. – SLaks Commented Jul 5, 2013 at 14:57 - 1 Sure, but we're talking about a client residing in the web browser here. Is it really wise (or even possible) to tweak something that is normally defined by the browser? – Brad Koch Commented Jul 5, 2013 at 14:59
- You're right; that's impossible. – SLaks Commented Jul 7, 2013 at 12:03
1 Answer
Reset to default 16We're simply using custom HTTP X- headers. Something like X-Client-Version and X-Client-Name.