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

In message <>, Mark Nottingham writes:

My 0.02 DKK:

In H1 Content-Length is part of the "framing layer", and therefore
we should not be tolerant of senders transmitting bogus values,
just like we don't allow H2 senders the option of bogus frame length.

>A pathological sender might send *more* bytes than Content-Length 
>indicates. In the strictest sense, this behaviour is conformant, because 
>it doesn't violate a MUST, but it clearly violates the intent of the 
>field, and harms interoperability. Unfortunately, this isn't 

This is where skipping this discussion during the H2 phase have
created a new class of problems of us:  In H2 the body has a true
length, as delinieated by the framing, in H1 that is only the
case with chunked.

In H2 C-L can be given any role/significance we prefer, but I
personally think we should treat H1 and H2 senders the same:  C-L
can only be sent if it is precise[1] otherwise leave it out, (and
use chunked in H1).

How the receiver reacts to a mismatch is a policy decision, which
should probably lean tolerant for missing bytes at human-driven
clients, in particular for huge objects, and be zero tolerance
for mistakes in all other cases[2].


[1] I do recoginize that significant performance improvements could
be had if we had C-L-hints in H2 and in H1 with chunked, but
overloading Content-Length would be too dangerous, maybe:

	 "Body-Length: 1024?"  -> This is only an estimate

	 "Body-Length: >1024"  -> At least this many bytes

	 "Body-Length: <1024"  -> No longer than this

[2] Postel's rule was for a network shared with all your
friends, we live in a network with all our enemies.

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Wednesday, 15 February 2017 07:24:05 UTC