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

On Dec 9, 2007, at 6:00 AM, Julian Reschke wrote:

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

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.


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

9.1.1 "In particular, the convention has been established that the GET  
and HEAD methods SHOULD NOT have the significance of taking an action  
other than retrieval."

9.3 "The GET method means retrieve whatever information (in the form  
of an entity) is identified by the Request-URI."

Seems to me that processing a GET request should not have any action  
on the server other than retrieval, and retrieves an entity identified  
by the Request-URI (and not, for instance, by any possible entity body).

Also, it seems that if a GET response that varies based on entity-body  
is allowed at all, it would have to be specified as uncacheable or it  
would break integrity of caches.

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

All right, I will admit that this is unclear (along with many other  
details of the HTTP protocol).

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

That doesn't seem right to me. HTTP client special-casing based on  
request method is required or recommended by the RFC in some cases:

- For TRACE, it is indisputably mandatory for an http client library  
to special-case the method (since it MUST NOT send an entity-body).
- For GET, HEAD and DELETE, it is unclear based on the current RFC  
whether the same special-casing is mandatory, forbidden or optional.
- Responses to OPTIONS, PUT and DELETE are not cacheable, apparently  
notwithstanding response headers.
- Responses to POST are not cacheable unless explicitly specified by  
Cache-Control or Expires response headers.
- Issuing a PUT, POST or DELETE should invalidate cached entities for  
the corresponding Request-URI.
- For GET, some special semantics are defined for conditional and  
range headers.

There are many other mentions of specific methods or groups of methods  
by name in the RFC. I did not carefully study which of those impose  
additional requirements for special cases based on request method on  
the client.

In general, an http client library that does caching will perform a  
variety of special-case handling based on particular request methods,  
request headers, and response headers.

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

Thanks for the suggestion, however I'm not sure this advice is  
applicable. And in any case it comes too late to affect the structure  
of already existing implementations, so does not have much effect on  
the pragmatic landscape.

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

The relevant input to this working group as far as HTTP is concerned  
is the appropriate RFCs. HTTPbis WG members may have useful  
information on the content of current or future RFCs, but it is  
certainly within this WGs purview to read and interpret the relevant  
specifications for ourselves.

Regards,
Maciej

Received on Sunday, 9 December 2007 15:27:14 UTC