- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Wed, 11 Jul 2012 20:43:55 -0500
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: ietf-http-wg@w3.org
Intermediaries are required to decompress a gzip transfer-coding? Intermediaries are forbidden to decompress gzip content-coding to look into the content? Intermediaries are forbidden to change Accept-Encoding and Content-Encoding? On Wed, Jul 11, 2012 at 7:15 PM, Amos Jeffries <squid3@treenet.co.nz> wrote: > On 12.07.2012 09:59, Zhong Yu wrote: >> >> Transfer-Encoding and Content-Encoding overlap in functionality. For >> example, gzip can be done in either way. But in reality, gzip is only >> implemented with Content-Encoding, for whatever reason. It might be >> safer to introduce a new content-coding than a new transfer-coding. >> > > The Content-Encoding is about the entity. End-to-End. > The Transfer-Encoding is about the channel. Hop-by-Hop. > > gzip is not implemented as Transfer-Encoding due to all the reasons Willy > and I put forward against mandatory gzip compression on SPDY connections. It > is a large performance loss to de/re-compress at every hop. chunked on the > other hand is trivial to recode and when used right increases performance. > > When implementing anything which intermediaries *need* visibility to and > possibly even manipulation of, Content-Encoding is the worst way to do it. > > AYJ > >
Received on Thursday, 12 July 2012 01:44:23 UTC