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

    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. 
There's a false dichotomy here.  It should be possible to separate the
problem of validating a cached response (is this the response that the
server would give for this variant) from the problem of determining
compatability between a specific response and a set of requests that
differ in their Accept headers (is this the variant that the server
would return).

I would agree that one could solve both problems by presenting every
request to the server, but I would not agree that this is the only
possible solution.  For example, if the origin server's response
contains sufficient information about the existence of other variants,
the cache could (in principle) decide that a non-expired ("fresh")
cached response obtained with one set of request headers is in fact
appropriate to return for a different set of request headers.


Received on Wednesday, 27 December 1995 17:30:33 UTC