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

On Dec 7, 2007, at 12:29 PM, Mark Baker wrote:

>
> On 12/7/07, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>
>> Bjoern Hoehrmann wrote:
>>>> Is it conforming for a UA to drop the body for GET requests?
>>>
>>> Not as far as I can tell.
>>
>> I'd like to request that this be changed, then.  Otherwise you're  
>> effectively
>> requiring UAs to rewrite their HTTP layers to support entity-bodies  
>> with GET
>> requests (or switch to using different HTTP libraries, etc).
>
> If you're using a library which doesn't support entity bodies on GET,
> then that can only be because it special cases GET when it shouldn't.
> Sounds like a bug to me.

 From the RFC2616, section 4.3: "A message-body MUST NOT be included  
in a request if the specification of the request method (section  
5.1.1) does not allow sending an entity-body in requests."

Chasing the pointers to Section 9, it appears that the methods from  
section 5.1.1 that explicitly allow sending an entity-body in requests  
are OPTIONS, POST and PUT. For TRACE, section 9 explicitly states that  
the request MUST NOT include an entity. For GET, HEAD and DELETE is is  
not stated whether they MAY include an entity-body or MUST NOT. It's  
unclear to me if this means they allow it or not. Does "does not  
allow" mean "does not (explicitly) allow" or "(explicitly) disallows"?  
So it may not be valid HTTP to send requests with those methods that  
include an entity-body, in which case it seems clearly non-buggy for  
http libraries to forbid sending a body in these cases. I hope future  
HTTP RFCs make it more clear whether these methods allow an entity-body.

Furthermore, the RFC-specified semantics and behavior of GET, HEAD and  
DELETE do not depend on the entity-body, only the Request-URI and  
request headers. It appears to me that a server would be in violation  
of RFC2616 if it ever did anything different in response to requests  
with these methods based on the contents or mere presence of an entity- 
body. On this basis too it seems acceptable for libraries to drop an  
entity-body sent with one of these methods; even if it legal to  
include an entity-body in such cases (which is dubious), it clearly  
can't make a difference to a conforming server, so there's no reason  
not to drop it.

And finally, pragmatically, at least some user agents have not allowed  
entity-bodies with GET requests, it may cause problems with servers in  
practice, and it seems like a significant burden to require support.  
It seems like a bad idea to impose a burdensome implementation  
requirement in order to support a use that has no valid use case.

Regards,
Maciej

Received on Sunday, 9 December 2007 13:16:16 UTC