- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 9 Jun 2009 11:49:58 +0200
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Jun 8, 2009, at 5:33 PM, Henrik Nordstrom wrote: > 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 Shouldn't that be in the definition of refreshing a cache? Perhaps we need more introductory material. > 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. I would go with the common sense, except keep in mind that the request fields for no-cache and no-store are for bypassing any cache entirely -- it is okay to ignore the response because the expectation is that the "cache" component is separate from the agent/proxy/gateway/origin component handling that request. > Example such conditions: > > * Cache-Control: no-store On a request, this is an instruction to the proxy/gateway to bypass the cache (if any). On a response to a validating request, it invalidates whatever is cached because it is new metadata. > * Cached response considered fresh by cache but not meeting request > requirements, and the new response is not cacheable. That invalidates the current cached item if the cache sent a validating request. > * As above, but cache for other reasons selects not to store the new > response. That is outside the protocol, I think. What matters is that the server's current instructions regarding the representation be understood (explained by the protocol). ....Roy
Received on Tuesday, 9 June 2009 09:50:35 UTC