Re: rethinking caching

>...
>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.
>...
>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.

Absolutely. A Vary: 1#(http-header-name) header returned by the server
would help solve this problem.

The 1.1 content negotiation mechanism is only of use for the
caching problem if the server provides the client/proxy with sufficient
information for it to do the document selection itself. The 1.1 draft
supports this in the limited cases where the variance can be expressed
by the URI: header.

The 1.1 mechanism is not of use when
1. The server does not provide individual URLs for all the possible documents
   that could be returned when accessing a URL.
2. The server may have URLs for the individual documents, but does not
   return an exhaustive list of possibilities (maybe it would be too large)
3. The document returned depends on a parameter in a manner that cannot
   be described by a URI: header. (e.g. available in multiple character sets.)

Without a Vary: header, servers will have to mark the response as not
cacheable.

 David Robinson.

Received on Wednesday, 20 December 1995 07:29:12 UTC