While tring to figure out why file uploads weren’t working in IE9 on SourceAudio, I discovered an interesting quirk: IE9′s user agent as reported by navigator.userAgent isn’t necessarily the same as the user agent that it sends in for http requests.
Apparently this is intended and understood behavior but it was the first I’d heard of it.
To summarize, MS found that as programs and add-ons added “feature tokens” to your user agent string, the length of the string would become so long that some servers would throw a fit. To prevent the issue, IE9 stopped adding these feature tokens when they send the user agent to the server, so instead of sending
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E)
You just send in
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
So why does that matter?
SourceAudio uses your user agent as salt for encryption so the server needs a consistent user agent. Ordinarily, the browser would always send the same one so it doesn’t matter but when doing flash uploads, flash doesn’t use the same user agent (or cookies, annoyingly) as your browser normally does so we have to send in the user agent manually using navigator.userAgent and suddenly it’s different.
As a solution, rather than sending in the user agent directly, we can just use
Which strips out all the feature tokens after the Trident version number, returning the user agent to the format that’s used for http requests.
Of course, that’s only a good idea for IE9 because previous versions sent in all the feature tokens, servers be damned, so you’ll want to either browser detect before applying the replace or try something like
IE9 is just Trident/5.0 but I threw in the 5-9 assuming future versions of IE will exhibit the same behavior.
I haven’t tried this in IE10. Can anyone report on its user agent behavior?