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

[Alex Rousskov <[e-mail]>]

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
them).

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.

Alex.


> ------ Original Message ------
> From: "Matthew Kerwin" <[e-mail]
> <mailto:[e-mail]>>
> To: "Adrien de Croy" <[e-mail] <mailto:[e-mail]>>
> Cc: "Alex Rousskov" <[e-mail]
> <mailto:[e-mail]>>; "[e-mail]"
> <[e-mail] <mailto:[e-mail]>>
> 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 <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>
>>
>>     ------ Original Message ------
>>     From: "Alex Rousskov" <[e-mail]
>>     <mailto:[e-mail]>>
>>     To: "Adrien de Croy" <[e-mail] <mailto:[e-mail]>>;
>>     "[e-mail] <mailto:[e-mail]>"
>>     <[e-mail] <mailto:[e-mail]>>
>>     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
>>   http://matthew.kerwin.net.au/