* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #23 (closed design: fixed)

Opened 7 years ago

Last modified 7 years ago

no-store invalidation

Reported by: mnot@pobox.com Owned by:
Priority: Milestone: unassigned
Component: p6-cache Severity:
Keywords: Cc:
Origin: http://lists.w3.org/Archives/Public/ietf-http-wg/2005JulSep/0004.html

Description

Responses to HTTP requests with "Cache-control: no-store" are not cachable. Recently, we came across a cache that does not cache responses to no-store requests but also does not invalidate an older cached entity with the same URL. When future requests stop using no-store, the old cached entity is served.

For example, the following happens in our test case:

  1. Client requests an entity A without using no-store.
  2. Cache proxies the transaction and caches the response (entity A).
  3. Client requests the same entity A using "Cache-control: no-store".
  4. Cache proxies the transaction and does NOT cache the response.
  5. Client requests the same entity A again, without using no-store.
  6. Cache serves the "old" entity A cached in step #2 above.

Does the cache violate the intent of RFC 2616 in step #6? If yes, should that intent be made explicit (I cannot find any explicit rules prohibiting the above behavior).

Change History

comment:1 Changed 7 years ago by mnot@pobox.com

  • version set to d00
  • Component set to cache
  • Milestone set to unassigned

comment:2 Changed 7 years ago by fielding@gbiv.com

I don't see any intent being violated in that example. An HTTP server must be able to interpret each request in isolation (HTTP is stateless by definition), so it really doesn't matter what requests came before the one which is answerable from the cache.

IMO, no change is needed.

comment:3 Changed 7 years ago by mnot@pobox.com

  • Status changed from new to closed
  • Resolution set to fixed

CLosed with no change.

Note: See TracTickets for help on using tickets.