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
