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

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

I did quote that section, but it doesn't define what an invalid C-L is.

Nowhere does it explicitly state that C-L value must equal the body size 
in order to be valid.  Sure it should be obvious, but the language at 
the start of 3.3.2 doesn't help there.

It says

"Any Content-Length field value greater than or equal to zero is
valid."

well no, to be valid it must match the body size.

The first sentence in 3.3.2

"When a message does not have a Transfer-Encoding header field, a
Content-Length header field can provide the anticipated size, as a
decimal number of octets, for a potential payload body."

"can provide"???
"anticipated size"???
"potential payload body"???

There's either a payload or there isn't.
C-L is either required or it isn't.
If size isn't known you can't send C-L, If it's a request you must use 
T-E chunked, since you can't close after sending and still receive the 
reply.

Adrien




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