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