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

Maciej Stachowiak wrote:
>  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.

This is a known issue, see 
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i19>.

> 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. 

I don't see why that would be a violation. As far as I can tell, some 
people consider it an extension point.

> 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.

It's not clear at all, IMHO, otherwise we probably wouldn't discuss 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.

On the other hand, the inability of a library/client/HTTP stack to pass 
a body in GET requests is a clear sign that it special-cases message 
passing behavior based on the request method, which would be a very bad 
design.

The HTTP spec defines the message format uniformly across methods (with 
the known exception HEAD), and thus I'd recommend to write 
implementations accordingly.

So please let the HTTPbis WG worry about how to resolve this issue; and 
do not step into areas not owned by this WG.

BR, Julian

Received on Sunday, 9 December 2007 14:00:54 UTC