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

[Willy Tarreau <[e-mail]>]

On Tue, Feb 14, 2017 at 09:12:38PM +0000, Adrien de Croy wrote:
> 
> I did quote that section, but it doesn't define what an invalid C-L is.
> 
> Nowhere does it explicitly state that C-L value must equal the body size in
> order to be valid.  Sure it should be obvious, but the language at the start
> of 3.3.2 doesn't help there.
> 
> It says
> 
> "Any Content-Length field value greater than or equal to zero is
> valid."
> 
> well no, to be valid it must match the body size.

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.

> The first sentence in 3.3.2
> 
> "When a message does not have a Transfer-Encoding header field, a
> Content-Length header field can provide the anticipated size, as a
> decimal number of octets, for a potential payload body."
> 
> "can provide"???
> "anticipated size"???
> "potential payload body"???

I think that's for 304 or responses to HEAD. Though out of the context,
the wording looks scary.

Regardless the text explaining how to determinate the body size (hence
where it stops once you've found where it starts) is pretty clear and
I hardly see how to interpret it differently.

You can make a parallel with a piece of string. Tell him "I'm giving you
2 meters of string, just pull it and cut at 2 meters, this is your body,
and what remains in my hand is mine and is not your body ; if I don't
tell you where to cut before pulling, you pull everything until I run
out of it and only then you can determine the length".

Anyway it's sad to see that there are people having so many difficulties
understanding so obvious concepts and that such people are allowed to
demand that a technical component works one way or another...

Willy