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
signature.asc
Description: Detta är en digitalt signerad meddelandedel
