Subject: Proposal for i23: no-store invalidation

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Apr 2008 13:17:54 +1100

<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/23>

To refresh your memory, the original discussion:
   http://lists.w3.org/Archives/Public/ietf-http-wg/2005JulSep/0004.html
with followup starting at:
   http://www.w3.org/mid/[email-masked]

My reading is that we think that no change is necessary here.

Comments?

--
Mark Nottingham     http://www.mnot.net/

---

From: Henrik Nordstrom <[email-masked]>
Date: Sun, 06 Apr 2008 00:25:35 +0200

> My reading is that we think that no change is necessary here.

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).

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Apr 2008 10:19:51 +1000

That seems like a different issue.

---

From: Henrik Nordstrom <[email-masked]>
Date: Tue, 08 Apr 2008 14:46:44 +0200

> 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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Apr 2008 18:58:53 -0700

> (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.

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 17 Apr 2008 10:28:16 +0200

> encountering a 5xx unless must-revalidate is present.

I am not talking about error responses. I am talking about this text
which currently is only specified for HEAD and not GET:

   If the new field values
   indicate that the cached entity differs from the current entity (as
   would be indicated by a change in Content-Length, Content-MD5, ETag
   or Last-Modified), then the cache MUST treat the cache entry as
   stale.

It's a equally good rule for GET as for HEAD, and having them aligned
would help getting rid of cornercases such as the i23 question.

> may change text regarding cache invalidation separately.

Yes. i23 requires no change. This is a separate but quite related issue.

Regards
Henrik

---

From: David Morris <[email-masked]>
Date: Thu, 17 Apr 2008 10:42:01 -0700 (PDT)

I think the assumption is that the reponse to the GET will
replace any earlier content in the cache. Why would an explicit statement
be needed?

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 17 Apr 2008 22:12:15 +0200

> replace any earlier content in the cache. Why would an explicit statement

Yes, but with no-store it doesn't..

and there may be a number of other occations when the cache for one
reason or another doesn't replace the earlier content, for example if
the fetch of the new version was aborted before it got cached.

Regards
Henrik