Re: RE: [XHR] Open issue: allow setting User-Agent?

> > The point is that a browser can act as if every single server response
> > included "Vary: User-Agent".  And perhaps should.  Intermediary caches
> > _certainly_ should.



Good suggestion.

Julian Aubourg wrote;
> > I'm still more concerned about potentially legitimate use cases of
> User-Agent filtering that could lead to security breaches when removing
> User-Agent from the non-modifiable list. But if no-one else feels like there

> could ever be such a legitimate use-case


So far we haven't heard from anyone who has seen or implemented such a solution in real life ;-).


> Neither do I disagree to take User-Agent header out of the non-modifiable
> list as far as we resolve the possible issues. Before we make decision, I
> would like to bring some other issues found in an article [1]:
> 
> > """ (quoted from [1])
> > A few of the problems include:
> > 
> > 1. Many websites will return only error pages upon receiving a UA header
> over a fixed length (often 256 characters).
> 
> Should we specify the length of the header that the script allows in the
> spec?



I think the spec should try to allow JS authors to work around buggy servers rather than attempting to work around server bugs ourselves. This may be a general issue with header lengths, though, just seen more frequently with User-Agent because of all the junk some setups add to it, but I don't think it makes sense to mandate that second argument to setRequestHeader() must be less than 256 characters.


If anything, this makes it more useful to be able to set User-Agent - if you're writing an app for users with lots of junk in the UA string and want to load data from a server that can't handle that ;-)


> > 2. In IE7 and below, if the UA string grows to over 260 characters, the
> navigator.userAgent property is incorrectly computed.
> 
> IE specific case. I don't think we will change the navigator.userAgent with
> XHR request.



Correct. This doesn't apply.


> > 3. Poorly designed UA-sniffing code may be confused and misinterpret
> tokens in the UA.
> 
> Sanitizing the header value could be considered.



We could, but figuring out some sensible rules that will handle the world wild web's poorly designed sniffing would take us a while ;-)
 
> > 4. Poorly designed browser add-ons are known to misinterpret how the
> registry keys are used, and shove an entire UA string into one of the

> tokens, resulting in a "nested" UA string.


This problem doesn't apply to us.

> > 5. Because UA strings are sent for every HTTP request, they entail a
> significant performance cost. In degenerate cases [2], sending the UA string
> might consume 50% of the overall request bandwidth.



Also something that's probably  best left to the JS author's unpredictable needs IMO.
-Hallvord


> [1]
> http://blogs.msdn.com/b/ieinternals/archive/2009/10/08/extending-the-user-ag
> ent-string-problems-and-alternatives.aspx
> [2]
> http://brianary.blogspot.com/2009/07/internet-explorer-user-agent-spam.html
> 
> 
> Jungkee

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Received on Wednesday, 17 October 2012 06:49:27 UTC