W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: i28 proposed replacement text

From: Jamie Lokier <jamie@shareable.org>
Date: Mon, 12 May 2008 18:52:08 +0100
To: Henrik Nordstrom <henrik@henriknordstrom.net>
Cc: Brian Smith <brian@briansmith.org>, Yves Lafon <ylafon@w3.org>, Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org
Message-ID: <20080512175208.GA17204@shareable.org>

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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC