W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: Proposal for i23: no-store invalidation

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 16 Apr 2008 18:58:53 -0700
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <A1D940B4-6869-4FBD-955D-3423248DB241@mnot.net>
To: Henrik Nordstrom <henrik@henriknordstrom.net>

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  

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC