W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: Request methods that allow an entity-body [i19]

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 22 Jan 2008 23:03:50 +1100
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Message-Id: <27D587F8-6E0C-4B2C-B21C-E436AA324E46@mnot.net>
To: Mark Baker <distobj@acm.org>

Looks like there's consensus on this one. I've recorded it in Trac and  
set a milestone for -02.

On 03/12/2007, at 4:48 AM, Mark Baker wrote:

> Ah, thanks Mark, I forgot about that discussion.
> IMO, the changes in your/Roy's proposal all impose requirements on
> implementations, and/or assume that defining new methods or response
> codes which cannot include an entity body is desirable.  I expect that
> as long as the meaning of the message is clear, then little more need
> be said.  And in order for the meaning to be clear, we just need to
> say that entity bodies don't alter the meaning of the message envelope
> around it (i.e. it can be ignored).
> However, that would be a pretty significant change that goes beyond
> the constraints of the charter.  So I'm content with your proposal
> because it does improve upon the current text.
> Mark.
> On 11/30/07, Mark Nottingham <mnot@mnot.net> wrote:
>> Previous to this, the most recent proposal on this issue (#19):
>>  <http://www.w3.org/mid/0B0A6372-C332-40A1- 
>> AF9D-252B8B1EF0BA@mnot.net>
>> Not too much discussion happened then; do we need a new proposal?
>> On 30/11/2007, at 7:29 AM, Mark Baker wrote:
>>> On 11/30/07, Scott Nichol <snicholnews@scottnichol.com> 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.
>>> --
>>> Mark Baker.  Ottawa, Ontario, CANADA.         http:// 
>>> www.markbaker.ca
>>> Coactus; Web-inspired integration strategies  http://www.coactus.com
>> --
>> Mark Nottingham     http://www.mnot.net/
> -- 
> Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
> Coactus; Web-inspired integration strategies  http://www.coactus.com

Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 22 January 2008 12:04:13 UTC

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