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

Re: i28 proposed replacement text

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Mon, 12 May 2008 19:20:47 +0200
To: Jamie Lokier <jamie@shareable.org>
Cc: Brian Smith <brian@briansmith.org>, Yves Lafon <ylafon@w3.org>, Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org
Message-Id: <1210612847.3442.9.camel@henriknordstrom.net>

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
Received on Monday, 12 May 2008 17:21:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:47 GMT