Re: P1: Content-Length SHOULD be sent

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)

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

On Tue, Dec 4, 2012 at 3:09 AM, Willy Tarreau <> wrote:
> Hi,
> On Tue, Dec 04, 2012 at 12:35:58AM -0600, Zhong Yu wrote:
>> Previously, a GET request should not contain a Content-Length header
>> (unless the client mischievously bundles a message body in a GET
>> request).
>> A server can legitimately reject a GET request with a Content-Length
>> header, since it is out of the norm, and the server isn't prepared for
>> it - dealing with request body is not trivial.
>> Now, if the proposed text is in effect, a programmer of a new client
>> reads the proposed text and sees that it's OK to add Content-Length:0
>> in a GET request; even worse, he'll probably reason that it is helpful
>> to set Content-Length:0, just to be clear. Yet such requests will be
>> rejected by that server.
>> So the proposed change could actually harm interoperability, since it
>> undermines the established practice and belief that GETs shouldn't
>> contain Content-Length.
> I don't see why you're saying this, because one of the point is :
>    o  the message is allowed to contain a body,
> If the GET message is not allowed to contain a body, then content-length:0
> is not needed. Also, I remember that somewhere it was indicated that no
> message body length indication in requests means there is no body. Ah,
> found it, it's in 3.3 :
>    The rules for when a message body is allowed in a message differ for
>    requests and responses.
>    The presence of a message body in a request is signaled by a a
>    Content-Length or Transfer-Encoding header field.  Request message
>    framing is independent of method semantics, even if the method does
>    not define any use for a message body.
> => a client sending "content-length:0" with a GET request explicitly
> says that there is a body in the request (which is empty). So it must
> be prepared to have its request rejected by some servers.
>> The current policy seems pretty good already: if there's no message
>> body, don't set Content-Length (with a few exceptions like in 304/HEAD
>> responses).
> Warning, you can't do that for responses, otherwise it means that the
> close determines the end of the message !
>> A client programmer will not benefit anyway from the
>> ability to set Content-Length:0 when there's no message body.
> Except in responses where this is needed if he wants to keep the connection
> alive.
> Regards,
> Willy

Received on Tuesday, 4 December 2012 15:43:23 UTC