W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: P1: Content-Length SHOULD be sent

From: Willy Tarreau <w@1wt.eu>
Date: Tue, 4 Dec 2012 22:30:44 +0100
To: Zhong Yu <zhong.j.yu@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, Martin Thomson <martin.thomson@gmail.com>, "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20121204213044.GA11107@1wt.eu>
On Tue, Dec 04, 2012 at 12:32:04PM -0600, Zhong Yu wrote:
> On Tue, Dec 4, 2012 at 10:45 AM, Willy Tarreau <w@1wt.eu> wrote:
> > On Tue, Dec 04, 2012 at 09:42:47AM -0600, Zhong Yu wrote:
> >> Yes a GET request can contain Content-Length, but people don't really
> >> do that. Based on that observation, a server may reject any GET with
> >> Content-Length, reasoning that it's simpler to program, and it won't
> >> lose any legitimate requests.
> >>
> >> However the proposed change may encourage new programmers to add
> >> Content-Length:0 to GET requests. (Actually it seems to be the sole
> >> motivation for the change)
> >
> > As I said, I don't think it encourages this due to the paragraph above
> > explicitly saying that requests without body don't need to send a c-l.
> > But maybe this could be reinforced in the text, I don't know.
> >
> >> This change will disturb the existing practices, without adding any value.
> >>
> >> (My real problem with the change is the semantics. A server API may
> >> want to distinguish between a request with an empty entity body and a
> >> request without an entity. Previously this can be done uniformly for
> >> requests, per RFC2616.)
> >
> > This distinction -if it exists at all- cannot be made based on the presence
> > of the content-length header field precisely because this one has been
> > optional for ages due to the compatibility with the close mode. My
> 
> I was referring to requests only.
> 
> > understanding has always been that no entity body is an empty body and
> > conversely.
> 
> An entity with an empty body can be non-trivial, because it can carry
> meanings in entity headers. It is different from not having an entity
> in a request.
> 
> For example, this is a legitimate request
> 
> POST /action HTTP/1.1
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 0
> 
> It is a form post with 0 parameters.
> 
> This is an illegitimate request:
> 
> POST /action HTTP/1.1
> Content-Type: application/x-www-form-urlencoded
> 
> It's a POST request without a body. Most web servers probably will reject it.

OK, so then if I understand you, we have two distinct cases :

  - responses always contain a body (except 1xx, 204, 304, HEAD) no matter
    what header we have ;

  - requests generally don't contain a body unless explicitly stated
    otherwise (eg: c-l: 0, or t-e: chunked + 0CRLF).

>From a pure messaging standpoint, that makes no difference, as both allow
the message parsers to keep in sync, but for a server consuming a request,
there is a semantical difference between saying "I'm not sending a body"
and "look, this is my body, and it's empty". That makes sense.

I think that everything is summarized in this part :

   6.  If this is a request message and none of the above are true, then
       the message body length is zero (no message body is present).

It ensures that all parties get the messaging right, but it does not
necessarily consider a different behaviour for a server. It's hard to
find how to change this to avoid introducing new issues or confusion.
Maybe the following sentence could simply be appended at the end of
the existing one :

       Some servers may require a message body with certain requests (for
       example, with POST or PUT methods). When a client knows that it is
       sending a request with an empty message body, it SHOULD explicitly
       state that a message body is present and of length zero in order to
       satisfy the server's requirements.

What do you think ?

Willy
Received on Tuesday, 4 December 2012 21:31:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 4 December 2012 21:31:24 GMT