Re: does no-store request invalidate?

    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)? 
    
I guess I share a big part of the responsibility for not getting
this issue clear in RFC2616.  To be honest, it's an unusual case;
all of the other cache-control directives are there to allow the
clients and servers to manipulate the externally-visible behavior
of a cache, and so it should be possible to work out the desired
behavior from the basic principles in section 13, especially these:

   Requirements for performance, availability, and disconnected
   operation require us to be able to relax the goal of semantic
   transparency. The HTTP/1.1 protocol allows origin servers, caches,
   and clients to explicitly reduce transparency when necessary.
   However, because non-transparent operation may confuse non-expert
   users, and might be incompatible with certain server applications
   (such as those for ordering merchandise), the protocol requires that
   transparency be relaxed

      - only by an explicit protocol-level request when relaxed by
        client or origin server

      - only with an explicit warning to the end user when relaxed by
        cache or client

However, no-store really has nothing to do with externally-visible
behavior, since there are other ways to get exactly the same
behavior (e.g., "cache-control: must-revalidate" in a response,
or "cache-control: no-cache" in a request).  The only reason
no-store was added to the protocol was to avoid "accidental
releases of information via unanticipated accesses to cache
data structures".  So it is really hard to figure out what it
is supposed to do for externally-visible behavior, since the
"intent" was that it would not be used to influence behavior!

Note that 13.1.1 (Cache Correctness) says

   A correct cache MUST respond to a request with the most up-to-date
   response held by the cache that is appropriate to the request (see
   sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
   conditions:    

I think the "principle of least astonishment" (as Dave Mills would
say) is that step #6 in Alex's example does not match an obvious
interpretation of "most up-to-date response ... that is appropriate
to the request", but on the other hand, I don't see anything in
RFC2616 that specifically prohibits step #6.

Overall, I would say that anyone who relies on externally-visible
behavior that is a specific side-effect of using no-store in
a request is making a mistake.   A client or server implementor
should use other cache-control directives to fully define the
visible behavior of caches.

This leaves open the denial-of-caching issue that Mark Nottingham
raised (i.e. an issue for implementors of shared proxy caches).
I think one has to make a judgement call here about whether there
is a significant risk of clients removing cache entries for each
other, and balance that against the possibility that a client
could end up with an out-of-date cached response (which seems
to me to be more likely to result in serious consequences).

One should note that the "editorial group" that ultimately was
responsible for the text of RFC2616 made an explicit decision
not to try to anticipate and define behavior for every possible
combination of HTTP request and response elements.  In the case
that Alex raises, we probably lacked any "intent" at all.

-Jeff

Received on Wednesday, 27 July 2005 21:39:03 UTC