Re: i28 proposed replacement text

Henrik Nordstrom wrote:
> > Imho, RFC 2616 section 4.4 rule 3 (Content-Length is not allowed with
> > transfer-coding) is illogical and inconsistent with Content-Length
> > being an entity header.  The rule is there only for compatibility, and
> > might be safe to relax in some cases where the receiver is known to
> > implement HTTP/1.1.
> 
> Maybe in some years. Something to revisit for HTTP/1.2.
> 
> The reals reason why it's there is to prevent badness when chunked
> encoding is removed by an intermediary hop and the advertised
> Content-Length does not match the acual length sent by chunked encoding.

Any intermediary which strips chunked (+ any other transfer-) encoding
and doesn't ensure what it sends matches Content-Length (and abort if
they don't) is buggy according to HTTP/1.1.

What makes you think HTTP/1.2 will fix that bug in implementations?

-- Jamie