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

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

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.

The Content-Length field value is an assertion of an attribute.

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