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

Re: XHR header blacklist rationale

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Tue, 27 May 2008 18:17:03 +0200
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "public-webapi@w3.org" <public-webapi@w3.org>
Message-ID: <onco349eijbmv5j99ciulh0dfo4l2poe63@hive.bjoern.hoehrmann.de>

* Julian Reschke wrote:
>Bjoern Hoehrmann wrote:
>> * Julian Reschke wrote:
>>> 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.
>> I think whether the client uses `Expect: 100-continue` is a decision
>> similar to deciding whether the client uses, say, a Transfer-Encoding.
>> The client may also be specifically configured to use a different
>> version of the protocol, like IE is configured to talk HTTP/1.0 to
>> proxy servers by default. Besides, the client may not even handle the
>> 100-continue response properly.
>What about "Expect: foobar"?

For all we know, `foobar` could be equivalent to 100-continue, in which
case the same considerations apply. I'm perfectly fine if a user agent
recognizes `foobar` and decides to pass the header along, I rather see
the purpose of the list of headers as reminding implementers that they
should make a concious decision with respect to these headers, rather
than simply and blindly block them. Calling it blacklist and embedding
it in SHOULDs and MUSTs does not strike me as useful.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Tuesday, 27 May 2008 16:18:51 UTC

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