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

Re: XHR header blacklist rationale

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 27 May 2008 15:12:52 +0200
Message-ID: <483C08D4.5050707@gmx.de>
To: Anne van Kesteren <annevk@opera.com>
CC: 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>

Anne van Kesteren wrote:
> On Tue, 27 May 2008 14:32:01 +0200, Julian Reschke 
> <julian.reschke@gmx.de> wrote:
>> So, why are the headers below on the list?
>>      * Accept-Charset
>>      * Accept-Encoding
>>      * Expect
>>      * Referer
>>      * User-Agent
> Because they are better handled by the user agent. Charsets and 
> encodings are transparent to the API and the user agent surely knows 
> Referer and User-Agent better.

I don't see why the client shouldn't be able to select a particular 
character set or encoding, even if it doesn't make a difference from the 
API point of view *for now* (it may when when we allow binary access).

But even now it may make sense to request a particular character set; 
for instance, if the object is plain text, but the UA selects a default 
character set that does not allow specific characters.

I also don't see why the client shouldn't have the option to set the 
Expect header; keep in mind that although 100-continue is the only 
expectation code defined in RFC2616, other codes can be defined as well, 
and it's not XHR's business to close that door.

Setting the user agent may be necessary when a server makes bad choices 
with respect to UA sniffing; for instance I have seen servers returning 
an HTML login form to things that identify themselves as IE, instead of 
doing HTTP auth.

For something to be on the black list, you really need really strong 

BR, Julian
Received on Tuesday, 27 May 2008 13:13:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:27 UTC