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

[Alex Rousskov <[e-mail]>]

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