- From: Koen Holtman <koen@win.tue.nl>
- Date: Sun, 28 Apr 1996 18:41:51 +0200 (MET DST)
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Cc: Koen Holtman <koen@win.tue.nl>
Here is new text for the cache replacement section. The change-bars are computer-generated. These changes reflect the removal of opaque selecting validators from the spec. To Jim Gettys: please perform the edits indicated below as soon as you can. Also, delete Section 13.12 (cache keys), except for sub-section 13.12.4 (Canonicalization of URIs), which should be merged with Section 3.2.2 (http URL). Koen. --snip-- 13.20 Cache Replacement for Varying Resources If a new 200 (OK) response is received from a non-varying resource while an old 200 (OK) response is cached, caches can delete this old response from cache memory and insert the new response. For 200 (OK) | responses from varying resources (Section 10.vary), cache replacement is more complex. HTTP/1.1 allows the authors of varying resources to guide cache | replacement by the inclusion of variant-IDs in the responses of these | resources. [##lots of complexity deleted here##] If a cache has | stored in memory a 200 (OK) response with a certain variant-ID, and receives, from the same resource, a new 200 (OK) response which has | the same variant-ID, this should be interpreted as a signal from the resource author that the old response can be deleted from cache memory and replaced by the new response. | The variant-ID mechanism cannot cause deletion from cache memory of old | responses with variant-IDs that will no longer be used. It is expected that the normal 'least recently used' update heuristics employed by caches will eventually cause such old responses to be deleted. | All responses from varying resources SHOULD include variant-IDs. If | these are not present, the resource author can expect caches to | correctly handle requests on the varying resource, but cannot expect | the caching to be efficient.
Received on Sunday, 28 April 1996 09:48:06 UTC