Re: i28 proposed replacement text

On mån, 2008-05-12 at 18:06 +0100, Jamie Lokier wrote:

> However, it is by far the common practice to use "Content-Encoding:
> deflate" (or gzip) instead.  User agents which decompress those send
> the appropriate Accept-Encoding.  In principle this reduces the work
> required by a proxy, but limits the ability of a proxy to compress
> some connections when one endpoint doesn't have the capability.  But
> in reality, Transfer-Encoding and Content-Encoding are virtually
> interchangable in this regard.

But they are not..  Content-Encoding creates a new entity, while
transfer-encoding is fully transparent.

> So that makes compression independent of transfer encoding.

?
> But then there's this small problem of bugs in old servers and user
> agents either setting or parsing Content-Length as the length _after_
> compression, which you might want to avoid.

Which is partly why specs clearly say that if Transfer-Encoding is used
then Content-Length MUST be ignored, with the small exception for the
now removed case of "Transfer-Encoding: identity".

Regards
Henrik