W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2002

RE: Entities

From: Larry Masinter <LMM@acm.org>
Date: Mon, 19 Aug 2002 08:19:57 -0700
To: "'Alex Rousskov'" <rousskov@measurement-factory.com>, "'Kim Horne'" <kim@pookzilla.com>
Cc: <ietf-http-wg@w3.org>
Message-ID: <001101c24793$e1791a50$6ace8642@masinter>

I should warn you that the issue of "GET with body"
has been controversial.

Let's look at the whole paragraph:

   The presence of a message-body in a request is signaled by the
   inclusion of a Content-Length or Transfer-Encoding header field in
   the request's message-headers. 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. A server SHOULD
   read and forward a message-body on any request; if the request method
   does not include defined semantics for an entity-body, then the
   message-body SHOULD be ignored when handling the request.

The problematic phrase is "does not allow": does this mean
the same thing as "forbids", or does it mean "does not explicitly
allow". And this is a problem because the definitions of
GET, HEAD and DELETE do not mention an entity-body, so they
don't "explicitly allow" one, but they also don't forbid one.

The method definitions for OPTIONS, POST, PUT mention entity
definitions and (for POST and PUT) their semantics. TRACE
explicitly disallows an entity-body; CONNECT and extension-methods
aren't defined. And that's all of the methods defined in
RFC 2616.

I believe (and I think the email record supports) that the
assumption has been that GET, HEAD and DELETE don't have
entity bodies and thus senders MUST NOT send one,
even though proxies and servers SHOULD read, forward
and (when processing) ignore one if they get one.

I also think this is the safest interpretation; certainly
it wouldn't be possible to add any semantics to entity
bodies for GET or HEAD, since proxies and other kinds of
intermediaries would discard them.

I'm tempted to call this an errata: we intended to write the
specification more clearly but failed to do so. However,
given the noise around 'GET with body', I suppose we
might need to treat this as an issue.

The main point of forbidding body with GET is the belief
that it would fail with large chunks of deployed infrastructure;
servers that would crash or give erroneous results if
presented with a GET with a body. I haven't seen any
reports, although I remember some speculation about this.

Received on Monday, 19 August 2002 11:19:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:35 UTC