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 


------ Original Message ------
From: "Alex Rousskov" <>
To: "Adrien de Croy" <>; "" 
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 
>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.
>>  ------ Original Message ------
>>  From: "Alex Rousskov" <>
>>  To: "" <>
>>  Cc: "Adrien de Croy" <>
>>  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 
>>>  valid. 0x123 is not. 0123 is valid unless the recipient is paranoid.
>>>>   Nowhere does it explicitly state that C-L value must equal the 
>>>>  size
>>>>   in order to be valid.
>>>  You are correct. The message framing rules ( establish 
>>>  C-L value and body length are the same concept (for the applicable 
>>>  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 
>>>  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 
>>>  5 tons".
>>>  HTH,
>>>  Alex.
>>>>   ------ Original Message ------
>>>>   From: "Loïc Hoguin" <>
>>>>   To: "Adrien de Croy" <>; ""
>>>>   <>
>>>>   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 
>>>>>>  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 
>>>>>>   length?
>>>>>   It sounds pretty explicit to me:
>>>>>      4.  If a message is received without Transfer-Encoding and 
>>>>>          either multiple Content-Length header fields having 
>>>>>          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 
>>>>>  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 
>>>>>          Content-Length header field, the Transfer-Encoding 
>>>>>  the
>>>>>          Content-Length.  Such a message might indicate an attempt 
>>>>>          perform request smuggling (Section 9.5) or response 
>>>>>          (Section 9.4) and ought to be handled as an error.
>>>>>   So sending a 400 and closing does not sound crazy even in that 
>>>>>   despite the spec not requiring it.
>>>>>   -- Loïc Hoguin

Received on Tuesday, 14 February 2017 23:19:03 UTC