- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Wed, 11 Jul 2012 21:54:43 -0500
- To: Amos Jeffries <squid3@treenet.co.nz>
- Cc: ietf-http-wg@w3.org
If there's not an official policy mandating different use of the two, I don't see any essential technical difference between transfer coding and content coding. TE: gzip => Transfer-Encoding: gzip chunked works equally well as Accept-Encoding: gzip => Content-Encoding: gzip for anyone on the path. On Wed, Jul 11, 2012 at 9:27 PM, Amos Jeffries <squid3@treenet.co.nz> wrote: > On 12.07.2012 13:43, Zhong Yu wrote: >> >> Intermediaries are required to decompress a gzip transfer-coding? >> > > Yes. Transfer Encoding must be removed when caching, when transforming, when > interpreting the body, or when transcoding to a hop with different > negotiated Transfer-Encoding type. > > There is a very limited set of middleware (essentially just SOCKS or VPN > tunnels) which can avoid it. All the rest have to implement the encoding. > > >> Intermediaries are forbidden to decompress gzip content-coding to look >> into the content? Intermediaries are forbidden to change >> Accept-Encoding and Content-Encoding? > > > Why do you insert this word "are forbidden to"? > > It is a *performance* loss issue, not a permission one, for the large > majority of intermediary types which do not need to touch the entity > integrity in any way. Just look at how many of the transforming proxies that > do content filtering find it necessary to force identity encoding from > servers just to operate at any reasonable speed. > > AYJ > >
Received on Thursday, 12 July 2012 02:55:11 UTC