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

Re: P1: Content-Length SHOULD be sent

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Tue, 4 Dec 2012 17:05:55 -0600
Message-ID: <CACuKZqEg8HUf7+G_Ft56LRHiMvHna+rNmfjcD=TuSh2BOcS2Yg@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
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>
On Tue, Dec 4, 2012 at 3:30 PM, Willy Tarreau <w@1wt.eu> wrote:
> 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).

I think it should simply state

    6.  If this is a request message and none of the above are true, then
        the message contains no body.

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

I don't think such clarification is necessary. It is clearly implied
that, if a request does not contain a body, it must not set
Content-Length or Transfer-Encoding; it a request contains a body, it
must set Content-Length or Transfer-Encoding, even if the body is

> What do you think ?
> Willy
Received on Tuesday, 4 December 2012 23:06:42 UTC

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