W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: rethinking caching

From: David Robinson <drtr1@cus.cam.ac.uk>
Date: Wed, 20 Dec 95 15:22 GMT
Message-Id: <m0tSQLW-000DJMC@ursa.cus.cam.ac.uk>
To: masinter@parc.xerox.com
Cc: drtr1@cus.cam.ac.uk, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>...
>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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:37 EDT