> -----Original Message----- > From: Brian Pane [mailto:brianp...@gmail.com] > Sent: Freitag, 4. Juni 2010 14:39 > To: dev@httpd.apache.org > Subject: Re: canned deflate conf in manual -- time to drop > the NS4/vary? > > 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
Isn't that what Transfer-Encoding is designed for? Regards Rüdiger
