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

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

From: Hallvord Reiar Michaelsen Steen <hallvord@opera.com>
Date: Wed, 17 Oct 2012 08:49:35 +0200
To: "Mark Baker" <mark@zepheira.com>, "Boris Zbarsky" <bzbarsky@mit.edu>, "Jungkee Song" <jungkee.song@samsung.com>
Cc: public-webapps@w3.org, "Julian Aubourg" <j@ubourg.net>
Message-ID: <11e7589edf95ab9feea1db493e590d22@opera.com>
> > 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.

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

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