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" <rousskov@measurement-factory.com>
> To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> Cc: "Adrien de Croy" <adrien@qbik.com>
> 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" <essen@ninenines.eu>
>>>  To: "Adrien de Croy" <adrien@qbik.com>; "ietf-http-wg@w3.org"
>>>  <ietf-http-wg@w3.org>
>>>  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
>>>
>>
>

Received on Tuesday, 14 February 2017 23:14:25 UTC