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

Re: [XHR] send doesn’t explain what to do when method is GET

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 15 Dec 2007 11:44:17 +0100
Message-ID: <4763B001.7030601@gmx.de>
To: Jonas Sicking <jonas@sicking.cc>
CC: Anne van Kesteren <annevk@opera.com>, Maciej Stachowiak <mjs@apple.com>, Mark Baker <distobj@acm.org>, Boris Zbarsky <bzbarsky@mit.edu>, Bjoern Hoehrmann <derhoermi@gmx.net>, public-webapi@w3.org

Jonas Sicking wrote:
>> Disagreed. Please do not try to standardize HTTP APIs that profile 
>> what HTTP allows.
> XHR already disallows a lot of things that HTTP allows. Setting certain 
> headers, cross site requests, etc. Why is this different?

XHR should only disallow things when there's a good reason to do so, 
that is, when the fact that XHR requests can be invoked by client-side 
script in HTML pages affects the security picture.

I don't see what that would have to do with GET bodies.

>> Besides that, Björn already reported that both IE7 and FF happily pass 
>> the body, as they should (IMHO).
> My reading of Björns email was that they did not drop it for HEAD, 
> OPTIONS and EXAMPLE did not drop the entity body. In my testing IE, 
> Firefox and Opera all dropped the entity body of GET requests.

OK. If an implementation behaves differently for GET and HEAD - *except* 
for handling the response body - this is very clearly a bug, as stated 
by Björn. Do you want to wire that bug into XHR?

> So if for no other reason, interoperability seems like a good argument 
> for stating that this should be done.

Again disagreed. Interoperability may be a good argument for warning 
people about a certain feature, not requiring everybody not to support it.

BR, Julian
Received on Saturday, 15 December 2007 10:45:00 UTC

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