Re: Sections 3.3.2 and 3.3.3 allow bogus Content-Length?

["Adrien de Croy" <[e-mail]>]

------ Original Message ------
From: "Willy Tarreau" <[e-mail]>
To: "Adrien de Croy" <[e-mail]>
Cc: "Loïc Hoguin" <[e-mail]>; "[e-mail]" 
<[e-mail]>
Sent: 15/02/2017 11:05:04 AM
Subject: Re: Sections 3.3.2 and 3.3.3 allow bogus Content-Length?

>On Tue, Feb 14, 2017 at 09:12:38PM +0000, Adrien de Croy wrote:
>>
>>  I did quote that section, but it doesn't define what an invalid C-L 
>>is.
>>
>>  Nowhere does it explicitly state that C-L value must equal the body 
>>size in
>>  order to be valid.  Sure it should be obvious, but the language at 
>>the start
>>  of 3.3.2 doesn't help there.
>>
>>  It says
>>
>>  "Any Content-Length field value greater than or equal to zero is
>>  valid."
>>
>>  well no, to be valid it must match the body size.
>
>In fact that's not true. It's not the content-length that matches the
>body size, it's the body which ends after the content-length. So 
>whatever
>numeric value >= 0 is indeed valid *and* defines the body size.
I think there's an argument you could make against this.

If the C-L is smaller than the transmitted body, then the remainder 
after C-L bytes is processed as an invalid new request, or maybe 
smuggling request.

If the C-L is larger than the transmitted body then the message is 
incomplete.  In a response message the connection would need to be 
closed, and in a request message there's no recovery from this.

An implementation may choose to just truncate the message at C-L bytes 
of body, but this is an implementation decision, not necessarily a 
specification?

I think it should be made clear that for the body and C-L to be both 
correct in terms of framing, the C-L value must match the size of the 
body in bytes, if there's a mis-match you can't claim C-L is correct.


>
>
>>  The first sentence in 3.3.2
>>
>>  "When a message does not have a Transfer-Encoding header field, a
>>  Content-Length header field can provide the anticipated size, as a
>>  decimal number of octets, for a potential payload body."
>>
>>  "can provide"???
>>  "anticipated size"???
>>  "potential payload body"???
>
>I think that's for 304 or responses to HEAD. Though out of the context,
>the wording looks scary.

Where did we end up with C-L on 304 responses?  I didn't think it was 
another case like HEAD where the 304 is the size of what would have been 
sent?


>
>
>Regardless the text explaining how to determinate the body size (hence
>where it stops once you've found where it starts) is pretty clear and
>I hardly see how to interpret it differently.
>
>You can make a parallel with a piece of string. Tell him "I'm giving 
>you
>2 meters of string, just pull it and cut at 2 meters, this is your 
>body,
>and what remains in my hand is mine and is not your body ; if I don't
>tell you where to cut before pulling, you pull everything until I run
>out of it and only then you can determine the length".
>
>Anyway it's sad to see that there are people having so many 
>difficulties
>understanding so obvious concepts and that such people are allowed to
>demand that a technical component works one way or another...

Or telling others this is how it works in a public Q&A forum.  It 
doesn't help anyone for this interpretation to propagate.

Adrien

>
>
>Willy
>