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: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 10 Dec 2007 06:47:37 -0800
Cc: Mark Baker <distobj@acm.org>, Boris Zbarsky <bzbarsky@mit.edu>, Bjoern Hoehrmann <derhoermi@gmx.net>, public-webapi@w3.org
Message-Id: <F3BDDADA-74F4-4F3A-92DC-09596D0C0A9C@apple.com>
To: Julian Reschke <julian.reschke@gmx.de>

On Dec 10, 2007, at 6:05 AM, Julian Reschke wrote:

>> I think my bottom line is the same as Boris's, I would like to see  
>> the spec allow XHR implementations not to send GETs with an entity- 
>> body.
> I would argue that both the simplest thing and the right thing here  
> is not to state anything at all, and let RFC2616bis clarify.

1) The RFC will only clarify the protocol issues (whether a GET  
request is allowed to have a body). I don't think that automatically  
specifies the behavior at the XMLHttpRequest API level. In particular  
if the RFC does not allow some kinds of requests to have a body, that  
doesn't define what should happen if you client code tries to include  
one anyway (exception? silently ignored? sent anyway? implementation- 
defined?). And conversely, if the RFC treats some set of things  
without special-casing, that doesn't automatically mean XHR can't  
special-case anyway, for example it special-cases a number of request  
headers already.

2) We could probably make up spec language that specifies this in  
terms of whatever the RFC ends up saying, but it would be pretty  

3) The spec as written doesn't "state nothing", it appears to clearly  
require sending an entity body and does not allow ignoring the body or  
throwing an exception regardless of what is allowed per RFC. So some  
change is needed, one way or another.

Received on Monday, 10 December 2007 14:47:56 UTC

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