On Fri, Jun 4, 2010 at 2:18 AM, Mark Nottingham <m...@mnot.net> wrote: [...] > It's not a bug in the implementations, it's a grey area in 2616 that HTTPbis > has since worked to resolve; > http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147
By my reading of the attachments in that ticket, servers (including caches) would be required to treat the following as equivalent to each other: Accept-Encoding: gzip, deflate Accept-Encoding: gzip,deflate Accept-Encoding: deflate, gzip Accept-Encoding: deflate,gzip and the following as different from each other: Accept-Encoding: gzip,deflate Accept-Encoding: gzip If so, the RFC 2616 patch would basically codify current good practices in cache configuration (I recall that the Varnish docs, for example, recommend normalizing the Accept-Encoding before using it in a cache key), and as such it would be a step forward. In practice, given a cache that implements these equivalence rules and an origin server that sets a Vary header on Content-Encoding, I'd expect the cache to end up holding up to three copies of each object: 1. compressed, with a cache key of something like URI+"gzip,deflate" 2. compressed, with a cache key of URI+"gzip" 3. uncompressed, with a cache key of URI+"" That's fewer copies of the object that the cache would end up with if it did a strict text match on the different permutations of "gzip,deflate"; but it's still a lot of copies. So I have to ask: why not reduce the number of copies to just one, by turning Content-Encoding into a hop-by-hop header and deprecating the use of Vary to indicate an Accept-Encoding-based variation? Cache implementors could then choose their own policies: - Store one copy of the object, compressed, to optimize for memory use - Store compressed and uncompressed copies of the object, to optimize for CPU use Brian