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

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

I disagree

Content-Length the concept is indeed the content length.

Content-Length the header is a _header_ which _represents_ 
Content-Length the concept.

It's a promise made by the sender that the sender will send that many 
bytes of body.

The only true size of a body is what you obtain by counting its bytes.  
The Content-Length header is not part of that body, it's sent in the 
headers, we parse it, convert the string to a number.

Yet we have no rule stating it must be consistent with what is sent.

I think we could be a little less timid about this and call it like it 
is.

Adrien


------ Original Message ------
From: "Alex Rousskov" <[e-mail]>
To: "Adrien de Croy" <[e-mail]>; "[e-mail]" 
<[e-mail]>
Sent: 15/02/2017 12:13:56 PM
Subject: Re: Sections 3.3.2 and 3.3.3 allow bogus Content-Length?

>On 02/14/2017 03:54 PM, Adrien de Croy wrote:
>>  I have no problem with the concept of adding a rule that states that
>>
>>  objects labelled as weighing 5T MUST weigh 5T or the label is
>>  incorrect/invalid.
>
>Thinking of Content-Length as a packaging label gets you into the very
>trap you want to escape: Yes, rules for labeling accuracy would be 
>fine,
>but Content-Length (in relevant contexts) is _not_ a label!
>Content-Length does not merely document weight that you can
>independently measure and validate. Content-Length _is_ weight.
>
>Alex.
>
>
>
>>  ------ Original Message ------
>>  From: "Alex Rousskov" <[e-mail]>
>>  To: "[e-mail]" <[e-mail]>
>>  Cc: "Adrien de Croy" <[e-mail]>
>>  Sent: 15/02/2017 11:38:17 AM
>>  Subject: Re: Sections 3.3.2 and 3.3.3 allow bogus Content-Length?
>>
>>>  On 02/14/2017 02:12 PM, Adrien de Croy wrote:
>>>
>>>>   I did quote that section, but it doesn't define what an invalid 
>>>>C-L is.
>>>
>>>  The term "valid" in that section means "syntactically correct". 123 
>>>is
>>>  valid. 0x123 is not. 0123 is valid unless the recipient is paranoid.
>>>
>>>
>>>>   Nowhere does it explicitly state that C-L value must equal the 
>>>>body
>>>>  size
>>>>   in order to be valid.
>>>
>>>  You are correct. The message framing rules (3.3.3.1-5) establish 
>>>that
>>>  C-L value and body length are the same concept (for the applicable 
>>>cases
>>>  where C-L value is used for framing and only for those cases).
>>>
>>>  In other words, one should not add a "C-L value MUST match the body
>>>  length" or "the body length MUST match the C-L value" rule because 
>>>the
>>>  body length _is_ the C-L value (for the applicable cases). Adding 
>>>such a
>>>  rule would be like saying "an object with a weight of 5 tons MUST 
>>>weigh
>>>  5 tons".
>>>
>>>
>>>  HTH,
>>>
>>>  Alex.
>>>
>>>
>>>>   ------ Original Message ------
>>>>   From: "Loïc Hoguin" <[e-mail]>
>>>>   To: "Adrien de Croy" <[e-mail]>; "[e-mail]"
>>>>   <[e-mail]>
>>>>   Sent: 15/02/2017 10:05:46 AM
>>>>   Subject: Re: Sections 3.3.2 and 3.3.3 allow bogus Content-Length?
>>>>
>>>>>   On 02/14/2017 09:49 PM, Adrien de Croy wrote:
>>>>>>
>>>>>>   The language in RFC 7230 section 3.3.2 is extremely non-commital
>>>>>>  about
>>>>>>   whether Content-Length needs to be correct or not.
>>>>>>
>>>>>>   I'm currently having a dispute about this with someone who 
>>>>>>quoted
>>>>>>  these
>>>>>>   sections at me as being proof that you can use any value for C-L
>>>>>>   regardless of the body length.
>>>>>>
>>>>>>   I think it could be a lot more forcefully written
>>>>>>
>>>>>>   Or is the person correct and we don't need to have C-L match the 
>>>>>>body
>>>>>>   length?
>>>>>
>>>>>   It sounds pretty explicit to me:
>>>>>
>>>>>      4.  If a message is received without Transfer-Encoding and 
>>>>>with
>>>>>          either multiple Content-Length header fields having 
>>>>>differing
>>>>>          field-values or a single Content-Length header field 
>>>>>having an
>>>>>          invalid value, then the message framing is invalid and the
>>>>>          recipient MUST treat it as an unrecoverable error.  If 
>>>>>this
>>>>>  is a
>>>>>          request message, the server MUST respond with a 400 (Bad
>>>>>  Request)
>>>>>          status code and then close the connection.
>>>>>
>>>>>   If it's both invalid and required for handling the request, send 
>>>>>a 400
>>>>>   and close the connection.
>>>>>
>>>>>   I suppose the spec allows you to have an invalid Content-Length 
>>>>>if and
>>>>>   only if the request also has a Transfer-Encoding header, however:
>>>>>
>>>>>          If a message is received with both a Transfer-Encoding and 
>>>>>a
>>>>>          Content-Length header field, the Transfer-Encoding 
>>>>>overrides
>>>>>  the
>>>>>          Content-Length.  Such a message might indicate an attempt 
>>>>>to
>>>>>          perform request smuggling (Section 9.5) or response 
>>>>>splitting
>>>>>          (Section 9.4) and ought to be handled as an error.
>>>>>
>>>>>   So sending a 400 and closing does not sound crazy even in that 
>>>>>case,
>>>>>   despite the spec not requiring it.
>>>>>
>>>>>   -- Loïc Hoguin
>>>>>   https://ninenines.eu
>>>>
>>>
>>
>