W3C home > Mailing lists > Public > public-webapi@w3.org > December 2007

(wrong string) €™t explain what to do when method is GET

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Sun, 09 Dec 2007 21:39:17 +0100
To: Maciej Stachowiak <mjs@apple.com>
Cc: public-webapi@w3.org
Message-ID: <dajol3t0chu3bsndsmflf6h8q8gp2kdokl@hive.bjoern.hoehrmann.de>

* Maciej Stachowiak wrote:
>It seems that pending resolution of this issue, it's inappropriate to  
>require XMLHttpRequest implementations to sometimes send requests that  
>may be in violation of the RFC.

In practise implementations have a hard time telling the difference be-
tween conforming and non-conforming requests, simply because they have
been written long before a script asks to make some request and the un-
derlying specifications may well have changed by then.

Tomorrow someone might make two new HTTP methods, one that requires an
entity body and one that prohibits one. Today's implementations cannot
tell the two new methods apart, and would either block legit requests,
or pass through malformed ones. Similarily, existing methods may be
changed one way or the other.

The same is true for headers, header values, entity bodies, and other
features. Ultimately you would be saying that making any requirements
whatsoever is inappropriate as there would be a non-zero chance that
at some point that would require implementations to violate some RFC.

Boris simply wants that implementations can conform to the draft with-
out sending entity bodies in GET requests. If we want to allow that,
we have to explain what they are to do instead (it seems they should
then raise a NotImplemented exception, but that is unfortunately not
possible without breaking content that uses .send('') as is somewhat
Bjrn Hhrmann  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 Sunday, 9 December 2007 20:39:24 UTC

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