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

[Loïc Hoguin <[e-mail]>]

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