- From: Jungkee Song <jungkee.song@samsung.com>
- Date: Tue, 16 Oct 2012 14:44:03 +0900
- To: 'Boris Zbarsky' <bzbarsky@MIT.EDU>
- Cc: public-webapps@w3.org, 'Hallvord Reiar Michaelsen Steen' <hallvord@opera.com>, 'Julian Aubourg' <j@ubourg.net>
> -----Original Message----- > From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] > Sent: Monday, October 15, 2012 9:50 PM > > On 10/15/12 7:18 AM, Jungkee Song wrote: > > but if certain backend intends to provide its content under some browser > requirements, isn't "Vary: User-Agent" sort of a required header to have > related caching proxy, if any, work correctly? > > Yes, it is, but it's rare for websites to think about that sort of thing > in my experience. > > In particular, I have yet to encounter a site that both does server-side > UA sniffing _and_ sends Vary: User-Agent. Yes, I think it's very rare. I found that a Korean web portal site, "Naver", does send "Vary:Accept-Encoding,User-Agent" upon the request to "http://www.naver.com" and "http://m.naver.com", though. > > Otherwise, subsequent requests on the same resource with different User- > Agent string would be regarded as a cache HIT in caching proxy anyway. > > Indeed. > > > Anyway, the point here is that if changing of User-Agent is allowed in > script, it will be possible for malicious third party to set arbitrary > User-Agent strings in generating XSS attacks. > > While true, a third party can already do this with things like botnets, > no? I'm not sure I see the additional threats here. Can you explain? >From that perspective, I don't think setting the User-Agent string in script poses any unknown treats. However, it seems like we are permitting another choice which is simply calling a JavaScript function. FYI, here is another article [1] written about the compatibility problem on changing the UA string at runtime. [1] http://blogs.msdn.com/b/ieinternals/archive/2009/10/08/extending-the-user-agent-string-problems-and-alternatives.aspx Jungkee
Received on Tuesday, 16 October 2012 05:44:35 UTC