- 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
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 UTC