Re: P1: Content-Length SHOULD be sent

On 27/11/2012 6:21 p.m., 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

Reading that thread I don't see anyone requiring CL on a GET. Just CL:0 
on a POST with no body - which seems correct.
> 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).

If I'm reading that right any recipient MUST consider a request with no 
Content-Length or Transfer-Encoding header as being 0-length.
   That opens a request smuggling loophole when overly zealous 
privacy/anonymizer config has been implemented. When proxy-A is known to 
erase CL headers (but obeys them) it can be sent a POST with smuggled 
request and victim request in pipeline. Proxy-A duly erases the CL and 
passes what server X is now required to interpret as three requests, 
resulting in proxy-A getting the smuggled requests response stored as 
the victums reply - and some garbage at the end of the pipeline.
  Bit rare, but I have seen people erasing every header they thought was 
optional because "some requests dont have it".


That paragraph also looks like a confusingly long set of conditionals to me.

What about something along the lines of:
   When a message is allowed to contain a body Content-Length SHOULD be 
sent, if the length of body is not known or is not easily retrieved in 
adavnce Transfer-Encoding:chunked SHOULD be used instead.

I am also inclined to suggest a MUST on there being some indication of 
length other than close. If that does not cause too many existing 
implementation to become invalid we have a chance to kill off that pesky 
close signal earlier rather than later.

Amos

Received on Tuesday, 27 November 2012 09:33:27 UTC