interaction of caching with content negotiation, authentication, state, etc

Larry Masinter writes:
 > I've been on vacation and just got back. I think the interaction of
 > 'content negotiation' and 'caching' can be limited to acknowledging
 > that:
 > 
 > * the value returned by applying a method to a URI depends on many
 > of the other headers in the request (including those supplied during
 > content negotiation, the user agent, etc.)
 > 
 > * the originating server needs to indicate which request headers were
 > involved in deciding what content to return, even if those request
 > headers are not replicated in the entity headers of the response
 > 
 > * a cache might legitimately keep around several cached values for the
 > same method applied to the same URI, and want to apply a
 > 'get-if-different' validator that would request validation of one of
 > the several cached values.
 > 
 > The same principle for caching applies for content negotiation,
 > authentication, and state sharing.


I think there are additional complications which require more
attention from the caching subgroup (though it's possible the
attention will boil down to dismissing this issue).

If it is possible for a given object to be returned in response to
requests on different URIs, as it would be with content negotiation
(among other possibilities), then either that object must be
pre-expired, so that it will be validated on every request, or it will
be possible for multiple versions of the object to be present in, and
servable from, a cache if the object changes at the origin server
prior to its stated expiration date.  The consequence of this is that
users might see previous versions of an object, even though they are
only using a single cache. 

>From a user's perspective, this is worse than consistently serving
a version that lags somewhat behind the "latest & greatest" version
from the origin server.

--Shel

Received on Friday, 22 December 1995 17:08:45 UTC