- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Mon, 08 Jun 2009 17:33:46 +0200
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
mån 2009-06-08 klockan 15:29 +0200 skrev Roy T. Fielding: > I don't follow. If the cache is involved in the request, then it will > invalidate the cached response when it receives a 200. If the cache > is not involved in the request (no-cache or no-store) then it has > no part in the communication and cannot be required to do anything. The thing is that there is nothing that says the cache should invalidate the previous response except implicit where the new response replaces the previous response in the cache. The exception is a couple special cases * HEAD responses * Negotiated resources with Content-Location There is several conditions where the new response won't get stored in the cache. Under those conditions there is no rule which tells caches how to deal with the older cached entry unless the request was a HEAD request or a negotiated resource... or at least that's my reading. Common sense says to apply the same rule as for HEAD responses, invalidating the prior response if the new response indicates significant change of the resource. It somewhat ties together with the invalidating requirement on negotiated resources when seeing two responses with same Content-Location but different entity-tag, or the requirement on invalidation on mismatching HEAD responses. Example such conditions: * Cache-Control: no-store * Cached response considered fresh by cache but not meeting request requirements, and the new response is not cacheable. * As above, but cache for other reasons selects not to store the new response. Regards Henrik
Received on Monday, 8 June 2009 15:34:27 UTC