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 22:38:48 UTC