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

Jeffrey Mogul writes:
 >     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.
 > 
 > -Jeff

I see your point, though I wonder how tractable your alternative would be.
To ensure cache coherency using the method I think you are suggesting,
each time a given object is returned in response to any request, the
server would have to indicate all the possible request URIs for which that
object might be returned (in addition, possibly, to the
content-negotiation info by which the object would be selected).

There is also a spoofing issue, especially in the present design with
its Location headers.  We can't let responses claim anything
that would allow the returned objects to be cached under a bogus key
that would allow later requests to erroneously return the object.
This is why people appropriately shot me down some months ago when I
suggested that, in order to solve the duplicate object problem as
mentioned above, caches replace any objects they contain that used the
same Location header.

So, the only thing I have been able to think of that will work --
by which I mean it will ensure cache coherence and also a
reasonable hit rate -- is for the cache to flush any other objects it
contains which claimed the same URI as the returned Location header,
but only if they do not have the same cache validator.

--Shel

Received on Thursday, 28 December 1995 11:09:11 UTC