W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

Re: XHR header blacklist rationale

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 28 May 2008 01:35:08 +0200
Message-ID: <483C9AAC.1040004@gmx.de>
To: Jonas Sicking <jonas@sicking.cc>
CC: Anne van Kesteren <annevk@opera.com>, Sunava Dutta <sunavad@windows.microsoft.com>, "public-webapi@w3.org" <public-webapi@w3.org>, Gideon Cohn <gidco@windows.microsoft.com>, Ahmed Kamel <Ahmed.Kamel@microsoft.com>, Zhenbin Xu <zhenbinx@windows.microsoft.com>, Doug Stamper <dstamper@exchange.microsoft.com>

Jonas Sicking wrote:
> These should absolutely not be under control of web content.
> 
> The Referer header is used by some web servers for security checks so 
> allowing this to be settable would work around that. Servers can't 
> currently rely on the header being there due to some firewalls/proxies 
> filtering it, however they can rely on it being true when it is there.
> 
> The User-Agent is used a lot for logging and measuring various aspects 
> (OS, UA, etc) of the user base for a site. Allowing this to be "spoofed" 
> by a web page would severely reduce its usefulness. You cite in a 
> different mail that you want to be able to set this to work around 
> servers that send different content based to different UAs based on this 
> header. However if we let this header be set by web content then servers 
> would not be able to rely on the User-Agent header and would likely 
> start using even worse mechanisms.

Microsoft's ActiveX version of XMLHTTPRequest definitively lets clients 
set it. I know it, because it was needed to override the UA header, so 
that servers would do proper authentication instead of form-based login.

Not sure about what the native implementations do today, but I think we 
need to make sure that the XHR spec doesn't break use cases that work today.

BR, Julian
Received on Tuesday, 27 May 2008 23:35:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 May 2008 23:35:52 GMT