- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 27 May 2008 15:12:52 +0200
- 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 arguments. BR, Julian
Received on Tuesday, 27 May 2008 13:13:39 UTC