W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

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

From: Jungkee Song <jungkee.song@samsung.com>
Date: Wed, 17 Oct 2012 13:17:18 +0900
To: 'Boris Zbarsky' <bzbarsky@MIT.EDU>, 'Mark Baker' <mark@zepheira.com>
Cc: 'Hallvord Reiar Michaelsen Steen' <hallvord@opera.com>, 'Julian Aubourg' <j@ubourg.net>, public-webapps@w3.org
Message-id: <01ab01cdac1e$4bfdc110$e3f94330$%song@samsung.com>
> -----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

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


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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:49 UTC