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:06:46 +0100
To: Brian Smith <brian@briansmith.org>
Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, Yves Lafon <ylafon@w3.org>, Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org
Message-ID: <20080512170646.GC15073@shareable.org>

Brian Smith wrote:
> Does this mean that it isn't possible to use deflate or gzip 
> Transfer-Encoding on a persistent connection unless chunked encoding is 
> applied (last)? And, doesn't the following imply that any 
> transfer-encoding (besides identity) must be chunked? That is, "deflate" 
> would not be a valid Transfer-Encoding, but "deflate, chunked" would me.

I believe that's correct: to use deflate on a persistent connection,
you must have "Transfer-Encoding: deflate, chunked".

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.

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.

-- Jamie
Received on Monday, 12 May 2008 17:07:22 GMT

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