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

Valid and matching the body length aren't quite the same, though.  I agree, it's a bit wishy-washy -- which sounds like one or more major implementations do something odd here that we didn't quite agree on invalidating.

However, in message framing, it does say that the length of the expected body is taken from the Content-Length header, and if the body doesn't match that you'll fail in odd ways.

-----Original Message-----
From: Loïc Hoguin [mailto:essen@ninenines.eu] 
Sent: Tuesday, February 14, 2017 1:06 PM
To: Adrien de Croy <adrien@qbik.com>; ietf-http-wg@w3.org
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 21:15:46 UTC