Re: P1: Content-Length SHOULD be sent

On Mon, Dec 3, 2012 at 10:40 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
> On 28/11/2012, at 11:10 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
>> On 27 November 2012 14:58, Mark Nottingham <mnot@mnot.net> wrote:
>>> When a message is allowed to contain a body, does not have a Transfer-Encoding header field, and has a payload body length that is known to the sender before the message header section has been sent, the sender should send a Content-Length header field to indicate the length of the payload body as a decimal number of octets, unless the message is a request and the method does not define any meaning for the body (in which case the Content-Length header MAY be sent).
>>
>> IANAL, so this was hard to parse for me.  How about:
>>
>> --8<--
>> The Content-Length header indicates the size of a message body as a
>> decimal number of octets.  The sender SHOULD set Content-Length if:
>>   o  the message is allowed to contain a body,
>>   o  the Transfer-Encoding header field is not included, and
>>   o  the size of the message body is known at the time that headers are sent.
>> Messages that do not define a meaning for the body MAY either omit the
>> Content-Length header field or include a value of 0.
>> -->8--

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.

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). A client programmer will not benefit anyway from the
ability to set Content-Length:0 when there's no message body.


> I think that's an improvement, delta some adjustments to align with terminology used elsewhere and a few other editorial tweaks. Read very strictly, there's a question of precedence between the requirements, but the intent is clear enough.
>
> I'll set this as the proposal in the ticket.
>
>
>> I'm leery of the "SHOULD" still.  It seems weak.  I'd almost go with
>> MUST include and a fourth condition: the message size is unknown and
>> the end of the body is signaled by closing the connection (in which
>> case the Connection header MUST include the 'close' token).
>
>
> I know what you're saying. However, I'm not sure the improvement is great enough to justify the ensuing discussion and back-and-forth...
>
> Cheers,
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>

Received on Tuesday, 4 December 2012 06:36:33 UTC