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
