- From: Paul Leach <paulle@microsoft.com>
- Date: Tue, 30 Apr 1996 17:17:05 -0700
- To: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, "'koen@win.tue.nl'" <koen@win.tue.nl>
Mentioning 200 (OK) responses is duplicative of text elsewhere in the spec, and does not include other cases that are allowed to be cached. Sections 13.14 and 10.7.2 give the rules for what may and may not be cached. This section should just say "cacheable responses" and cross-ref those sections. Furthermore, sections 13.11.2 and 13.11.3 say that caches SHOULD only return the latest response received; hence a new cacheable response SHOULD replace an older cached one -- a little stronger than "guidance". Finally, this section actually gives the cache replacement rules for both varying and non-varying resources, so it might better be titled simply "Cache Replacement". A replacement section 13.20 is appended. Paul =================== > > 13.20 Cache Replacement > > If a new cacheable response (according to the rules in > sections 10.7.2 and 13.14) is received from a non-varying resource > while an old response is cached, caches SHOULD delete this old > response from cache memory and insert the new response. > If a cache has a cached response for a varying resource > with a certain variant-ID, and > receives, from the same resource, a new cacheable response which has > the same variant-ID, this means that the old response SHOULD be deleted from the > cache and replaced by the new response. > > Note: 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 Tuesday, 30 April 1996 20:08:34 UTC