Subject: Request methods that allow an entity-body

From: "Scott Nichol" <[email-masked]>
Date: Thu, 29 Nov 2007 17:34:34 -0500

Section 4.3 states

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

I do not see any place in the specification where it says that any 
request does not allow sending an entity-body.  I might guess that GET 
and HEAD do not allow an entity-body, but isn't the spec supposed to 
remove guesswork?  The spec would be better if, for each request method, 
it were stated whether or not an entity-body is allowed.

Scott Nichol

---

From: "Mark Baker" <[email-masked]>
Date: Thu, 29 Nov 2007 19:44:33 -0500

This question pops up every few years.  Read this thread over;

http://lists.w3.org/Archives/Public/ietf-http-wg/2002JulSep/thread.html#msg24

Mark.

-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

---

From: David Morris <[email-masked]>
Date: Thu, 29 Nov 2007 16:55:48 -0800 (PST)

Which agrees with the point that this was incompletely specified in the
RFC. http://lists.w3.org/Archives/Public/ietf-http-wg/2002JulSep/0026.html

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 30 Nov 2007 14:16:33 +1300

that post does, but if you follow the thread through, Roy spells out 
clearly what the requirements are, that being that message parsing 
should not be dependent on the method, and that therefore (except for 
HEAD response for legacy reasons), one should not assume that any 
message (request or response) may not have an entity body.  If any 
message is to have an entity body, it must have a non-zero 
Content-Length header, or a Transfer-Encoding header.

This is required for extensibility - the ability of existing 
infrastructure to deal with new methods, which may or may not need to 
use entity bodies in requests.

This is also why there's an explicit requirement for proxies to forward 
unknown methods (depending on admin policy of course, but must be 
capable of doing it).

Regards

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: "Scott Nichol" <[email-masked]>
Date: Fri, 30 Nov 2007 09:12:45 -0500

One of Roy's posts 
(http://lists.w3.org/Archives/Public/ietf-http-wg/2002JulSep/0031.html) 
says

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

The original portion of the spec I was questioning is

<quote>

If Roy says "HTTP allows a message body on any request", then why does 
the second sentence in the above even appear in the spec?

I was concerned that the spec does not say in the description of any 
request method that an entity-body is not allowed.  Based on what Roy 
says, the spec is correct: there is no request method for which an 
entity-body is not allowed.  That an entity-body for a HEAD or GET would 
be "useless" is not relevant.  A client is allowed send one and a server 
must parse it.

What does "must parse it" imply?

I raised this issue because of a specific problem between NuSOAP and 
lighttpd.  The former sends a GET with Content-Length: 0 when fetching 
WSDL.  The latter responds with "400 Bad Request" because of the 
message-body.  Would that server behavior be considered out of spec? 
The server presumably "parsed" the request.

Scott Nichol

----- Original Message ----- 
From: "Adrien de Croy" <[email-masked]>
To: "David Morris" <[email-masked]>
Cc: "Mark Baker" <[email-masked]>; "Scott Nichol" 
<[email-masked]>; <[email-masked]>
Sent: Thursday, November 29, 2007 8:16 PM
Subject: Re: Request methods that allow an entity-body

> This is also why there's an explicit requirement for proxies to 
> forward unknown methods (depending on admin policy of course, but must 
> be capable of doing it).
>
> Regards
>
> Adrien
>
> David Morris wrote:
>> RFC. 
>> http://lists.w3.org/Archives/Public/ietf-http-wg/2002JulSep/0026.html
>>

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 30 Nov 2007 15:50:06 +0100

On fre, 2007-11-30 at 14:16 +1300, Adrien de Croy wrote:
>  If any 

That rule is for requests messages only, and is all there is to request
parsing for determining if there is a body or not.

For responses the rules are much broader for legacy reasons with
HTTP/1.0 & 0.9.. covered by the next paragraph in 4.3 Message Body.

Regarding request bodies and GET/HEAD/DELETE I think most have settled
to accept what the specs currently says. Request-bodies technically
being allowed but their meaning unspecified in those methods.

The specification as written is quite specific on the subject, but
people do get confused as the semantic meaning of a request body is
unspecified for GET/HEAD/DELETE.

  - As already indicated the request message parsing rules for
deretmining if there is a request body is simply

   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.

  - So is the handling any such request body even when unspecified by
the method.

   if the request method
   does not include defined semantics for an entity-body, then the
   message-body SHOULD be ignored when handling the request.

  - And forwarding of such body by proxies & servers to the processing
agent

   A server SHOULD
   read and forward a message-body on any request

All quotes from 4.3 Message Body

Now this is how recipients should process the message. Not how the
client may compose the message. 

I am all for extending the specifications of GET/HEAD/DELETE to include
a SHOULD NOT

   Requests sent using this method SHOULD NOT include a request body.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 30 Nov 2007 16:24:13 +0100

> the second sentence in the above even appear in the spec?

There is two sides of this.

One thing is what parsers (servers) must accept. Another how clients may
construct requests. If the method 

Specifications on how messages may be constructed is stricter than how
messages should be parsed/processed. Crossreading the two areas of the
specification as if they were one gets a bit confusing and is not how
the spec is intended to be read.

But yes, the sentence "A message-body MUST NOT be included in a request
if the specification of the request method does not allow sending an
entity-body in requests" is a bit ambigious. Does it mean that sending
an entity-body is not allowed if explicitly denied by the method
specification, or does it also mean that sending a body is not allowed
unless explicitly allowed by the method specifications. The difference
is the GET/HEAD/DELETE methods..

I read it the second way, that client MUST NOT include a body unless
explicitly allowed by the method specification. But it's clearly
specified what should happen at the server should a client send it a
such message with a request-body so it doesn't really matter that much.

> That an entity-body for a HEAD or GET would 

Yes.

> What does "must parse it" imply?

That it manages to read the body and ignore it when it has no meaning.
It MUST NOT misread the body as the next request.

> The server presumably "parsed" the request.

It's not entirely out of spec as the requirement to accept request
bodies is just a SHOULD, not a MUST. But it's not the desired behavior
to reject such messages.

Regards
Henrik

---

From: "Mark Baker" <[email-masked]>
Date: Fri, 30 Nov 2007 10:29:35 -0500

> the second sentence in the above even appear in the spec?

Those aren't inconsistent, but I reckon trying to be prescriptive in
that way makes little sense as, IMO, it should be a best practice not
to define methods which preclude entity bodies, if only for reasons of
extensibility.  *shrug*

> What does "must parse it" imply?

There's no requirement that the server *do* anything with the entity body.

> The server presumably "parsed" the request.

Yes, the server is buggy.

FWIW, the message that kicked off the thread I referenced came to be
because of the same problem; some client (the Swiss HttpClient IIRC)
inserting "Content-Length: 0" and a server (Tomcat) choking on it.

Mark.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 30 Nov 2007 11:52:55 -0800

Previous to this, the most recent proposal on this issue (#19):
   <http://www.w3.org/mid/[email-masked]>

Not too much discussion happened then; do we need a new proposal?

On 30/11/2007, at 7:29 AM, Mark Baker wrote:

>> inclusion

--
Mark Nottingham     http://www.mnot.net/