- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 16 Apr 2008 18:58:53 -0700
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
You wrote: > Not sure. It would make sense to generalize the HEAD invalidation to > also apply to GET responses. i.e. copy the text from HEAD to GET as > well. There is a whole family of uncachable responses, and the result > things can get very surprising if caches do not invalidate the older > copy when the resource has obviously changed even if the current > representation can not be cached.. > > But no-store in itself is not a parameter to that decision, only the > fact that the response is significantly different from the cached > copy. > > And it's not about caches deleting the cached copy, only > invalidating it > (threat it as stale on future requests). Can you give some examples? 4xx to a GET shouldn't invalidate the cache, and a cache is allowed to return a cached response when encountering a 5xx unless must-revalidate is present. Or are you just saying that 5xx + must-revalidate = invalidate? I can see a case for augmenting the text in p6-cache regarding HEAD invalidations (currently only mentioned in p2-semantics), and for aligning the HEAD text with that for 304 responses (p6-cache 7.2). Is that what you want? I suspect that's going to be part of a larger p6 rewrite... In any case, I believe we can close this issue with no spec change; we may change text regarding cache invalidation separately. On 08/04/2008, at 5:46 AM, Henrik Nordstrom wrote: > > tis 2008-04-08 klockan 10:19 +1000 skrev Mark Nottingham: >> That seems like a different issue. > > Yes, but related as it's mainly visible when using no-store. I would > say > it's the root issue of the no-store invalidation question. > > Regards > Henrik > > -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 17 April 2008 01:59:48 UTC