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. The drawback is that you end up with as many copies of the same entity as there is slight variations in Vary related headers. Example: A document available in en and de languages: Accept-Language: en Accept-Language: en-gb Accept-Language: en, sv Accept-Language; en, sv;q=0.7 etc all map to the en language entity, but if you do not follow 13.6 then the cache is unaware that these all results in the same entity and N copies of the "Content-Language: en" response entity is cached. In caches following 13.6 only a single copy of the "Content-Language: en" response entity is stored, shared by all the Accept-Language header combinations known to result in that entity identified by ETag. The cache learns this request -> entity mapping by using If-None-Match. Variants in HTTP is about the response entity. Request headers select the variant, but they do not identify the variant. 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. Regards Henrik
signature.asc
Description: Detta är en digitalt signerad meddelandedel
