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 10:09:36 +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: <20121204090936.GD5772@1wt.eu>
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 09:10:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 4 December 2012 09:10:14 GMT