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

On 02/14/2017 06:45 PM, Adrien de Croy wrote:

> If we turn it around, under what circumstances could we consider that 
> a user-agent emitting a request message which includes a Content-Length
> header whose value is greater than the number of bytes it then transmits
> after the headers

> Is not an error condition,

Never. That is, it is always an error condition.

> or that the message should be processed as if it were complete?

When the receiving agent is configured to work around certain well-known
error conditions (because the decision makers have decided that
rejecting the request under those conditions will make things worse for

FWIW, I do not recall any such conditions on the request receiving side
in Squid (other than those already documented as tolerable in the HTTP
specs), but there are some framing-related hacks on the response
receiving side IIRC.

> I also wonder whether we would be having a similar discussion on the TLS
> WG about record lengths.

There is essentially no difference at the protocol level AFAICT. Are
there any hacks in some SSL implementations to accommodate known error
conditions? I do not know. Compared with plain text HTTP, the difficulty
in writing an SSL agent from scratch combined with outlawing older
protocol versions probably helps minimize the long-term need for such
hacks. Said that, Squid still has to deal with ancient SSLv2 records
(containing TLS v1 messages)...

> When security is at stake I thought we tended to take a firmer stand.

I do not think this thread contained any recommendations not to take a
firm stand. The only disagreement was whether the protocol is missing
some MUSTs that would help making that stand easier.

> It seems from the language in 3.3.3 par 4 that the intention is that the
> C-L MUST match the body payload size.

Since C-L defines the body/payload size, the two always match. This
equivalence allows the recipient to determine when it got a truncated
message or post-message garbage.


> ------ Original Message ------
> From: "Matthew Kerwin" <
> <>>
> To: "Adrien de Croy" < <>>
> Cc: "Alex Rousskov" <
> <>>; ""
> < <>>
> Sent: 15/02/2017 2:18:43 PM
> Subject: Re: Sections 3.3.2 and 3.3.3 allow bogus Content-Length?
>> On 15 February 2017 at 10:42, Adrien de Croy <
>> <>> wrote:
>>     ------ Original Message ------
>>     From: "Alex Rousskov" <
>>     <>>
>>     To: "Adrien de Croy" < <>>;
>>     " <>"
>>     < <>>
>>     Sent: 15/02/2017 1:32:04 PM
>>     Subject: Re: Sections 3.3.2 and 3.3.3 allow bogus Content-Length?
>>         On 02/14/2017 04:18 PM, Adrien de Croy wrote:
>>              The only true size of a body is what you obtain by
>>             counting its bytes.
>>         I disagree. The only true size of a body is the Content-Length
>>         value (in
>>         relevant contexts).
>>     What about for a sender piecing a message together.  Where does
>>     Content-Length come from?
>>     The content existed before you derived or obtained its length.
>> When we say "content" do we mean content of the message, content of
>> the representation, or content of the resource? I've always taken
>> content-length to mean the content of the representation[*] -- which,
>> since the demise of T-E, basically means message payload.
>> When we say "body", I hope we're all always talking about message
>> payload. (i.e.: representation · Range · T-E)
>> Reasoning about the _/resource/_ (including file size) is the purview
>> of the application, outside of HTTP transport or semantics. At least,
>> that's how it looks from my ivory tower.
>> [*] something something Range something
>> Cheers
>> -- 
>>   Matthew Kerwin

Received on Wednesday, 15 February 2017 05:38:32 UTC