httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Akins <brian.ak...@turner.com>
Subject Re: Wrong etag sent with mod_deflate
Date Tue, 12 Dec 2006 14:20:59 GMT
Henrik Nordstrom wrote:
> mån 2006-12-11 klockan 14:25 -0500 skrev Brian Akins:
> 
>> So, multiple variants of the same object can have the same Etag, but still be 
>> different cached objects.
> 
> Your implementation ignores RFC 2616 13.6 Caching Negotiated Responses,
> but is otherwise fine. It's functionally compliant but not as effective
> as it could be.

That was a simplified explanation, we actually do not store a cache entry for 
every single variant.  In our case the only thing we actually ever care about is 
whether or not you support gzip.  So all the variants for "Vary: User-Agent, 
Accept-Encoding" actually boil down to 2 variants - gzip or no-gzip.

One of the major reasons we quit using squid was it "support" for Vary's. (This 
was pre-3.0, so things may have changed). Of course, at the time httpd wasn't 
any better - but it was alot easier to hack ;)


 >Variants is
 >identified by ETag or Content-Location. Only if there is neither ETag or
 >Content-Location in the response entity then is the response entity
 >identified by the Vary request headers.

Only conditional requests from clients, generally, have If-None-Match headers. 
So the only way for a cache, on an initial request from a client, to determine 
what object to serve is to use the Client supplied information - which doesn't 
include an Etag, so you have to, usually, rely on URI first, and then the Vary 
information.


-- 
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies

Mime
View raw message