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

> -----Original Message-----
> From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU]
> Sent: Wednesday, October 17, 2012 2:09 AM
> 
> On 10/16/12 1:04 PM, Mark Baker wrote:
> > That would be an improvement, but wouldn't solve the problem of
> > intermediary cache poisoning.
> 
> Ah, yes. Intermediary caches are indeed a problem.  I don't see anything
> the browser can do to solve that problem, unfortunately.
> 
> On the other hand, caches that don't assume "Vary: User-Agent" are
> already completely broken on the web when they sit between multiple
> users using multiple browsers and the rest of the web....
>
> > Julian Aubourg wrote;
> >> Couldn't we simply state in the spec that browsers must add the User-
> Agent header to the Vary list, all the time?
> >
> > Vary is a response header, set by the server.
> 
> 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.
>

Yes, that could solve the issue, but it seems we cannot avoid the
intermediary caching proxy problem unless server actually put "Vary:
User-Agent" in every response. I'm wondering if it's still worth to put it
into spec.


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, then I don't think we should hold
back because of this out-of-cache XSS attack: let's just specify User-Agent
has to be in Vary all the time. It's not like it will break caching in the
general case anyway.

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?

> 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.

> 3. Poorly designed UA-sniffing code may be confused and misinterpret
tokens in the UA.

Sanitizing the header value could be considered.

> 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.
> 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.
> """

[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

Received on Wednesday, 17 October 2012 04:17:51 UTC