rethinking caching

When you do an HTTP method for a URL, the results may depend on things
other than the method name and the path of the URL.  To control
caching, the source has to tell any client and proxy what things the
results depended on other than the URI. Sometimes those things are the
client's headers (accept:, accept-language:, authentication, state)
and sometimes those things are external to what the client sent (date,
client IP address, etc., whether the client has a license)

A client/proxy that has a cached resource for a URL may want to invoke
the same method for the same URL but with different parameters, or in
a different context, e.g., when the date has changed, or a helper app
has been added and the accept headers might be different, etc.

In those cases, the client/proxy needs to ask the server for the
results of applying the method to the URL, but also indicate to the
server which objects it DOES have cached for that URL.

If a site at Canada were to run a proxy cache for the site, it might
have cached documents for both the French and English versions of a
URL. Different clients should be able to retrieve the French and
English versions from the cache without clearing or 'invalidating' the
cache for the other clients who want the other language; modifying the
English version shouldn't cause the French version to get dropped from
the cache.

Most of the current proposals for headers back and forth don't handle
this situation correctly. Yet a straight-forward enumeration of
'depends-on' in the return from the server to the proxy, along with
proxy services that preserve that information and also all headers
that comprise the things the value returned depended upon, would be a
good first step. For some headers, (accept, for example), you need
more than merely knowing what it depended upon, but also the WAY in
which it depended upon the original data, so that the proxy itself can
decide whether a cached item is appropriate.

Received on Thursday, 14 December 1995 13:11:01 UTC