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

> -----Original Message-----
> From: Hallvord Reiar Michaelsen Steen [mailto:hallvord@opera.com]
> Sent: Wednesday, October 17, 2012 3:50 PM
> 
> > > 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.


But my concern was even if browser acts as such, intermediary caches would still return forged content in its cache rather than trying to make a fresh request to origin server. That is, authors would expect that they are free from cache poisoning threat based off of the spec, but it might not be true when caching proxy is involved. Unless server itself actually puts "Vary: User-Agent" in the response, we cannot entirely avoid the cache poisoning scenario.


Jungkee

> 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 07:37:12 UTC