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

From: Henrik Nordstrom <[email-masked]>
Date: Sun, 02 Dec 2007 16:33:42 +0100

On fre, 2007-11-30 at 11:52 -0800, Mark Nottingham wrote:
> 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?

I think it's fine.

Regards
Henrik

---

From: "Mark Baker" <[email-masked]>
Date: Sun, 2 Dec 2007 12:48:13 -0500

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 <[email-masked]> wrote:
> On 30/11/2007, at 7:29 AM, Mark Baker wrote:
>
> >
> > On 11/30/07, Scott Nichol <[email-masked]> 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

---

From: Robert Siemer <[email-masked]>
Date: Sat, 8 Dec 2007 18:32:09 +0100

On Fri, Nov 30, 2007 at 02:16:33PM +1300, Adrien de Croy wrote:

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

1) Where exactly did you find anything explicit for unknown methods? 
   Especially a forward-must...
2) It would be new to me that the spec does force an implementation to 
   contain code for something that can perfectly be switched off.
   Where does the spec require such a useless thing?

Regards,
		Robert

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 10 Dec 2007 06:07:01 +0100

>    Especially a forward-must...

I can't find any, but have a strong feeling there should be a "a
transparent proxy MUST forward.." and is also how I have understood the
spirit of the RFC, just as there is such a rule for extension-headers in
7.1 entity headers.

>    Where does the spec require such a useless thing?

More or less every SHOULD is in the above category (can be switched
off). But it doesn't make them useless.

Forwarding of extension methods is not useless. It's what allows the
protocol to evolve with WebDAV, CalDAV etc, etc..

Regards
Henrik