Re: P1: Content-Length SHOULD be sent

On 28/11/2012, at 6:28 AM, Roy T. Fielding <fielding@gbiv.com> wrote:

> 
> On Nov 26, 2012, at 9:21 PM, Mark Nottingham wrote:
> 
>> Currently, p1 says:
>> 
>>> When a message is allowed to contain a message 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.
>> 
>> This unqualified SHOULD leads people to convoluted readings of the spec where Content-Length is required to be sent on a GET request:
>> https://github.com/kennethreitz/requests/issues/223#issuecomment-10745532
>> 
>> Proposal:
>> 
>>> 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 payload length is zero (in which case the Content-Length header MAY be sent). 
> 
> That would be incorrect, so I don't see why it is being suggested.
> Try it with POST on a valid CGI script and it will result in a
> parser failure (if not a segfault).

Because the current text reads that you SHOULD send C-L: 0 on a GET.

How about:

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






--
Mark Nottingham   http://www.mnot.net/

Received on Tuesday, 27 November 2012 22:59:12 UTC