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

and I understand the argument that the header value defines the length 
of the body.

But that doesn't help with what happens if the actual body sent is 
different to what is advertised.

You can say that by definition if moe are sent, then they are not body 
by definition, but what if fewer are sent?

It's an incomplete message.

Maybe this should be turned around, so that byte sent MUST equal C-L 
advertised.  I'm just saying they should match and we shouldn't have a 
problem stating that, or stating that a mis-match is a fatal error.

Adrien


------ Original Message ------
From: "Adrien de Croy" <adrien@qbik.com>
To: "Alex Rousskov" <rousskov@measurement-factory.com>; 
"ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 15/02/2017 12:18:24 PM
Subject: Re: Sections 3.3.2 and 3.3.3 allow bogus Content-Length?

>
>I disagree
>
>Content-Length the concept is indeed the content length.
>
>Content-Length the header is a _header_ which _represents_ 
>Content-Length the concept.
>
>It's a promise made by the sender that the sender will send that many 
>bytes of body.
>
>The only true size of a body is what you obtain by counting its bytes.  
>The Content-Length header is not part of that body, it's sent in the 
>headers, we parse it, convert the string to a number.
>
>Yet we have no rule stating it must be consistent with what is sent.
>
>I think we could be a little less timid about this and call it like it 
>is.
>
>Adrien
>
>
>------ Original Message ------
>From: "Alex Rousskov" <rousskov@measurement-factory.com>
>To: "Adrien de Croy" <adrien@qbik.com>; "ietf-http-wg@w3.org" 
><ietf-http-wg@w3.org>
>Sent: 15/02/2017 12:13:56 PM
>Subject: Re: Sections 3.3.2 and 3.3.3 allow bogus Content-Length?
>
>>On 02/14/2017 03:54 PM, Adrien de Croy wrote:
>>>  I have no problem with the concept of adding a rule that states that
>>>
>>>  objects labelled as weighing 5T MUST weigh 5T or the label is
>>>  incorrect/invalid.
>>
>>Thinking of Content-Length as a packaging label gets you into the very
>>trap you want to escape: Yes, rules for labeling accuracy would be 
>>fine,
>>but Content-Length (in relevant contexts) is _not_ a label!
>>Content-Length does not merely document weight that you can
>>independently measure and validate. Content-Length _is_ weight.
>>
>>Alex.
>>
>>
>>
>>>  ------ Original Message ------
>>>  From: "Alex Rousskov" <rousskov@measurement-factory.com>
>>>  To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
>>>  Cc: "Adrien de Croy" <adrien@qbik.com>
>>>  Sent: 15/02/2017 11:38:17 AM
>>>  Subject: Re: Sections 3.3.2 and 3.3.3 allow bogus Content-Length?
>>>
>>>>  On 02/14/2017 02:12 PM, Adrien de Croy wrote:
>>>>
>>>>>   I did quote that section, but it doesn't define what an invalid 
>>>>>C-L is.
>>>>
>>>>  The term "valid" in that section means "syntactically correct". 123 
>>>>is
>>>>  valid. 0x123 is not. 0123 is valid unless the recipient is 
>>>>paranoid.
>>>>
>>>>
>>>>>   Nowhere does it explicitly state that C-L value must equal the 
>>>>>body
>>>>>  size
>>>>>   in order to be valid.
>>>>
>>>>  You are correct. The message framing rules (3.3.3.1-5) establish 
>>>>that
>>>>  C-L value and body length are the same concept (for the applicable 
>>>>cases
>>>>  where C-L value is used for framing and only for those cases).
>>>>
>>>>  In other words, one should not add a "C-L value MUST match the body
>>>>  length" or "the body length MUST match the C-L value" rule because 
>>>>the
>>>>  body length _is_ the C-L value (for the applicable cases). Adding 
>>>>such a
>>>>  rule would be like saying "an object with a weight of 5 tons MUST 
>>>>weigh
>>>>  5 tons".
>>>>
>>>>
>>>>  HTH,
>>>>
>>>>  Alex.
>>>>
>>>>
>>>>>   ------ Original Message ------
>>>>>   From: "Loïc Hoguin" <essen@ninenines.eu>
>>>>>   To: "Adrien de Croy" <adrien@qbik.com>; "ietf-http-wg@w3.org"
>>>>>   <ietf-http-wg@w3.org>
>>>>>   Sent: 15/02/2017 10:05:46 AM
>>>>>   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 23:25:45 UTC