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

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

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

>On 02/14/2017 04:18 PM, Adrien de Croy wrote:
>
>>  The only true size of a body is what you obtain by counting its 
>>bytes.
>
>I disagree. The only true size of a body is the Content-Length value 
>(in
>relevant contexts).

What about for a sender piecing a message together.  Where does 
Content-Length come from?

The content existed before you derived or obtained its length.

>The number of bytes counted by the sender or
>recipient do not change the message body length. Yes, there could be
>garbage after the body and, yes, something may prevent sending or
>receiving of the whole body, but none of that changes what the body 
>size is.
>
>If you define the message body size as the number of bytes sent or
>received (in relevant contexts), then you may add rules about those
>numbers, but HTTP specs do not define the message body size that way.
>
>Alex.
>
>
>
>>  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
>>>>>>
>>>>>
>>>>
>>>
>