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

On Tue, Feb 14, 2017 at 10:13:56PM +0000, Adrien de Croy wrote:
> > 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.
> I think there's an argument you could make against this.
> 
> If the C-L is smaller than the transmitted body, then the remainder after
> C-L bytes is processed as an invalid new request, or maybe smuggling
> request.
> 
> If the C-L is larger than the transmitted body then the message is
> incomplete.  In a response message the connection would need to be closed,
> and in a request message there's no recovery from this.
> 
> An implementation may choose to just truncate the message at C-L bytes of
> body, but this is an implementation decision, not necessarily a
> specification?

But that's exactly what happens in practice. In a request you don't want
to forward more than C-L because whatever follows is a new request (eg:
pipelining). In a response, if some bytes follow the C-L, it can be an
error message when the server closes on time-out. If the C-L announces
too large a message, the server may wait forever to consume the request
message, while too long a C-L in a response, followed by a close simply
indicates to the client a bad network condition with a connection cut
in the middle of the transfer (ie it may retry with a byte-range to get
the missing part).

> I think it should be made clear that for the body and C-L to be both correct
> in terms of framing, the C-L value must match the size of the body in bytes,
> if there's a mis-match you can't claim C-L is correct.

But that's really the point I do not understand well given that it defines
the body size. Imagine you transmit a body made of many requests, followed
by a series of similar requests. You can easily imagine that only the C-L
can tell where the end is :

POST / HTTP/1.1
Host: foo
Content-length: 100

POST / HTTP/1.1
Host: foo
Content-length: 100

POST / HTTP/1.1
Host: foo
Content-length: 100

POST / HTTP/1.1
Host: foo
Content-length: 100

POST / HTTP/1.1
Host: foo
Content-length: 100

POST / HTTP/1.1
Host: foo
Content-length: 100

...
etc.

Only the C-L here can let you now how many real requests you have because
even if visually some look like requests, they are not, they are just an
opaque body.

> > I think that's for 304 or responses to HEAD. Though out of the context,
> > the wording looks scary.
> 
> Where did we end up with C-L on 304 responses?  I didn't think it was
> another case like HEAD where the 304 is the size of what would have been
> sent?

It's specified that you have to ignore it for the framing (as well as on
HEAD and 204). I've seen it wrongly set in the past on some servers (a
long time ago), causing interoperability breakage (it was set to 0,
causing intermediary caches to truncate their bodies). By definition,
HEAD, 204 and 304 don't carry a body.

> > 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...
> 
> Or telling others this is how it works in a public Q&A forum.  It doesn't
> help anyone for this interpretation to propagate.

Stupid people claiming to be experts on public forums have always existed,
and it's only their attendees' fault if they believe them instead of reading
the official specs. We are responsible (and possibly faulty) for any unclear
info in the spec but at least it's written with the expectation that any
reader will have a measurable IQ and we've done a lot to even address some
lack of common sense... It could also be used as a test to say "if you can't
get it you're not allowed to implement anything for me"...

Willy

Received on Wednesday, 15 February 2017 06:53:58 UTC