httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <>
Subject Re: canned deflate conf in manual -- time to drop the NS4/vary?
Date Fri, 04 Jun 2010 12:38:36 GMT
On Fri, Jun 4, 2010 at 2:18 AM, Mark Nottingham <> wrote:
> It's not a bug in the implementations, it's a grey area in 2616 that HTTPbis has since
worked to resolve;

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


View raw message