httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrik Nordstrom <...@squid-cache.org>
Subject Re: Wrong etag sent with mod_deflate
Date Wed, 13 Dec 2006 02:21:09 GMT
tis 2006-12-12 klockan 09:20 -0500 skrev Brian Akins:

> Only conditional requests from clients, generally, have If-None-Match headers. 

Correct. It's a conditional. These days you also see them from Squid
btw.

> 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.

Indeed. This is always the case. If-None-Match MUST NOT be used for
identification of which response to use. It's a conditional only.

But the unique identity of the response entity is defined by request-URI
+ ETag and/or Content-Location. The cache is not supposed to evaluate
Accept-* headers in determining the entity identity, only the origin
server.

The identity of the entity is important for

- Cache correctness, making sure updates invalidate cached copies where
needed.

- Avoiding duplicated storage

There may be any number of request header combinations in any Vary
dimensions all mapping to the same entity.

This logics is not at all unique for Accept-Encoding. The logics on how
a cache is supposed to operate applies equal to all Vary indicated
headers. The specs does not make any distinction between
Accept-Encoding, Accept-Language, User-Agent etc in how caches are
supposed to operate. It all boils down to the entity identified by URI +
ETag and/or Content-Location as returned in 200 and 304 responses
allowing the cache to map requests to entities.

Please see RFC2616 13.6 Caching Negotiated Responses, it explains how
the RFC intends that caches should operate wrt Vary, ETag and
Content-Location in full detail.

Regards
Henrik

Mime
View raw message