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
