Re: i28 proposed replacement text

Henrik Nordstrom wrote:
> 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.

Sure, they are conceptually quite different.  But in practice it can
be a treated as a mere configuration issue.

The real work does not have to be different.  A proxy can forward a
gzip transfer-encoded entity without decoding and reencoding it (same
work/buffering as content-encoding), and just as it can use a
different encoding on the incoming and outgoing links, it can also
(non-transparently) be configured to change the content-encoding.  I
acknowledge issues with Etag, range requests, non-transparency etc.

Doing that is not a HTTP proxy per spec, but it done nonethless in
some configurations, and it is useful.

> > So that makes compression independent of transfer encoding.
> 
> ?

In practice.

> > 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".

I was meaning Content-Length in conjunction with Content-Encoding, not
Transfer-Encoding.

-- Jamie

Received on Monday, 12 May 2008 17:52:53 UTC