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

[Jacob Champion <[e-mail]>]

On 02/14/2017 02:13 PM, Adrien de Croy wrote:
>> In fact that's not true. It's not the content-length that matches the
>> body size, it's the body which ends after the content-length. So whatever
>> numeric value >= 0 is indeed valid *and* defines the body size.
> I think there's an argument you could make against this.
>
> If the C-L is smaller than the transmitted body, then the remainder
> after C-L bytes is processed as an invalid new request, or maybe
> smuggling request.
>
> If the C-L is larger than the transmitted body then the message is
> incomplete.  In a response message the connection would need to be
> closed, and in a request message there's no recovery from this.

I think Willy's point is that, from a protocol perspective, C-L 
*defines* the body (for the types of messages we're discussing here). 
It's not possible to transmit a body -- for HTTP's definition of "body" 
-- that is "smaller" or "larger" than the C-L. In one case, the endpoint 
runs out of bytes to read and eventually times out. In the other, it 
reaches the end of the body, and now there happens to be junk data at 
the start of the next received message.

> An implementation may choose to just truncate the message at C-L bytes
> of body, but this is an implementation decision, not necessarily a
> specification?

Well, there's this part of 3.3.3:

    If the final response to the last request on a connection has been
    completely received and there remains additional data to read, a user
    agent MAY discard the remaining data or attempt to determine if that
    data belongs as part of the prior response body, which might be the
    case if the prior message's Content-Length value is incorrect.  A
    client MUST NOT process, cache, or forward such extra data as a
    separate response, since such behavior would be vulnerable to cache
    poisoning.

which to me seems like a MAY that is doomed to fail in the general case. 
Broken pipelining, race conditions, cache poisoning...

--Jacob