- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Tue, 4 Dec 2012 17:05:55 -0600
- 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 empty. > What do you think ? > > Willy >
Received on Tuesday, 4 December 2012 23:06:42 UTC