Subject: Entities

From: Kim Horne <[email-masked]>
Date: Wed, 14 Aug 2002 08:25:14 -0400

I've come across what may or may not be an issue in RFC2616.  In section 
4.3 (Message Body) there is a line that reads:

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

However, there is no reference to such restrictions in 5.1.1.  It seems 
logical that it could be referring to GET and HEAD requests, but I can't 
find an answer anywhere else in the document.

Are GET/HEAD requests allowed to have entities or should section 5.1.1 
(or possibly 9.3/9.4 ?) have errata on this issue?  Is there something 
in the RFC on this issue that I'm missing?  Any help would be greatly 
appreciated...

--
Kimberly Horne

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 14 Aug 2002 11:10:36 -0600 (MDT)

On Wed, 14 Aug 2002, Kim Horne wrote:

> I've come across what may or may not be an issue in RFC2616.  In
> section 4.3 (Message Body) there is a line that reads:
>
> "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."
>
> However, there is no reference to such restrictions in 5.1.1.  It
> seems logical that it could be referring to GET and HEAD requests,
> but I can't find an answer anywhere else in the document.

Section 5.1.1 is essentially a table-of-contents for request method
specifications. For example, "GET" is described in Section 9.3. Thus,
I think the RFC wording is acceptable.

> Are GET/HEAD requests allowed to have entities or should section
> 5.1.1 (or possibly 9.3/9.4 ?) have errata on this issue?  Is there
> something in the RFC on this issue that I'm missing?  Any help would
> be greatly appreciated...

As far as I can see, RFC 2616 does not prohibit use of entity bodies
in GET or HEAD. Thus, according to the section 4.3, there might be a
body transmitted with those requests:

   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.

How many servers/proxies would be confused by GET bodies is a
different question.

HTH,

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 15 Aug 2002 14:49:00 -0700

> entity-body in requests."

http://www.w3.org/Protocols/HTTP/Issues/BeforeLastCall.html
issue 119 "MESSAGE-BODY",
and thread started with
http://ftp.ics.uci.edu/pub/ietf/http/hypermail/1997q3/0393.html

It looks like we didn't actually close this issue well enough,
since it's still being raised. Certainly the archive record is that
the intent was (for compatibility) to disallow bodies for
GET, HEAD and DELETE, but possibly allow bodies on other
methods unless explicitly disallowed (for extensibility's
sake).

---

From: Kim Horne <[email-masked]>
Date: Fri, 16 Aug 2002 09:59:10 -0400

> methods unless explicitly disallowed (for extensibility's

Aha! This answers my question nicely, thank you.  I was unaware of the 
existance of the Last Call document.

The reason I brought this up was because I was running into a problem 
where a piece of client software was adding a "Content-Length: 0" header 
to all GET requests it sent.  All the webservers that I tried it on 
completed the requests without complaint but when a (transparent) squid 
proxy was added into the mix it stopped working (with a 411 response 
code, of all things).  I wasn't sure which end of the problem I should fix.

Thanks!

---

From: Alex Rousskov <[email-masked]>
Date: Sun, 18 Aug 2002 14:40:29 -0600 (MDT)

> > http://ftp.ics.uci.edu/pub/ietf/http/hypermail/1997q3/0393.html

The discussion at the above URL implies that some part of the RFC
prohibits bodies for GETs. Could anybody point to that part? I do not
see anything prohibiting bodies in Section 9.3 "GET".

> The reason I brought this up was because I was running into a
> problem where a piece of client software was adding a
> "Content-Length: 0" header to all GET requests it sent.  All the
> webservers that I tried it on completed the requests without
> complaint but when a (transparent) squid proxy was added into the
> mix it stopped working (with a 411 response code, of all things).
> I wasn't sure which end of the problem I should fix.

Hmm.. I am surprised you are sure now, but perhaps I am missing
something in the RFC that the above URLs helped you find. To me, it
still looks like the RFC does not prohibit (and, hence, allows) bodies
for GETs. Please clarify.

Thanks,

Alex.

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 19 Aug 2002 08:19:57 -0700

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.

Larry
-- 
http://larry.masinter.net

---

From: Jeffrey Mogul <[email-masked]>
Date: Mon, 19 Aug 2002 16:16:49 -0400 (EDT)

Larry Masinter writes:

    

Here's a little thought experiment: Can we construct an example
request that is ambiguous if the server DOES accept a body for
a GET?

For example,

	<open TCP connection>
	GET /foo.html HTTP/1.1
	Host: example.com
	
	GET /bar.html HTTP/1.1
	Host: example.com
	Connection: close
	<close TCP connection>

Is this example:

    (a) a pipelined connection with two GETs for distinction URLs?
    
    (b) a single GET whose "body" looks a lot like the headers for
    another GET, but is actually just a BODY.

Probably if the example had included an explicit Content-length
field in the first group of headers, the ambiguity would go
away, but I think the Message Length rules (section 4.4) don't
require that.

My vote: treat this as an erratum; ban bodies for GET, HEAD, and
DELETE.

-Jeff

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 19 Aug 2002 15:15:17 -0700

> away, but I think the Message Length rules (section 4.4) don't

There is no ambiguity.  No content-length in a request means length == 0.

> My vote: treat this as an erratum; ban bodies for GET, HEAD, and

No.  You may think of this as just "clarifying" the spec, but in reality
it changes the parsing algorithm on the server such that the server
must know the semantics of every message that passes through it, such
that extensibility of methods becomes impossible.  The server already
has an unambiguous algorithm for interpreting the length of a message.

Whether or not GET allows a message body is irrelevant.  HTTP allows a
message body on any request.  The fact that clients should not send
useless bodies does not lessen the requirement of servers to parse a
message independent of the message semantics.  The only exception is
HEAD responses, and that only because of legacy issues.

....Roy

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 19 Aug 2002 21:43:55 -0700

Roy, you're mixing server and client responsibilities. It's
quite possible to mandate "must not send a body with GET" for
clients and also mandate "must parse and ignore message bodies
with GET" for servers.

> > My vote: treat this as an erratum; ban bodies for GET, HEAD, and

I think this was mandated for legacy reasons.

> HEAD responses, and that only because of legacy issues.

While this is mandated for future extensibility.

I don't think the two are incompatible.

---

From: Jeffrey Mogul <[email-masked]>
Date: Tue, 20 Aug 2002 13:40:31 -0400 (EDT)

> away, but I think the Message Length rules (section 4.4) don't

Roy Fielding writes:

My mistake.  I must have missed the part of RFC2616 that says
this.  In fact, I still can't find it; perhaps you could point
out the specific normative language?

-Jeff

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 20 Aug 2002 14:44:08 -0700

> out the specific normative language?

Section 4.3 of RFC 2068 says

    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 MAY be included in a
    request only when the request method (section 5.1.1) allows an
    entity-body.

and in RFC 2616 it says

In both cases, the first sentence is unambiguous.  The example you gave
had neither Content-Length nor Transfer-Encoding.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 20 Aug 2002 15:00:15 -0700

> clients and also mandate "must parse and ignore message bodies

Just the opposite. I was stating the requirement as it is currently
written -- separating server and client responsibilities.  The message
parsing algorithm does not know about method semantics aside from
HEAD responses.  Whether or not a body is included with GET is not
determined by the method semantics -- a server that does not anticipate
and correctly parse a GET request with a body is not compliant with
the protocol.

Adding yet another requirement to HTTP just to say that a
client MUST NOT send a body with GET, HEAD, DELETE, etc., will not
change the interoperability of the current protocol and it absolutely
must not change the message parsing algorithm (the example that Jeff
was talking about).  Doing so only eliminates the possibility that
future extensions might use the request body for those methods.

....Roy