Re: Request methods that allow an entity-body

On 11/30/07, Scott Nichol <> wrote:
> The original portion of the spec I was questioning is
> <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>
> 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?

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*

> 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?

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

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

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 Baker.  Ottawa, Ontario, CANADA.
Coactus; Web-inspired integration strategies

Received on Friday, 30 November 2007 15:29:56 UTC