Re: Rewrite of 13.12 (Cache keys)

The entire section 3.12 is wrong, and overspecification anyway, so
just delete it.  Define the interface, not how its implemented!

Why it is wrong:

There is only one cache key and that is the Request-URI (plus Host
if it is a server-side cache like Harvest).  No matter what the
request profile may be, and how that may affect variant selection,
the key is always the Request-URI.  The key points to an entry which
consists of cache-relevant information about the resource and a list
of pointers to the responses the cache has received from prior requests
on that Request-URI.  The cache then uses the current request profile,
compares it to the cache-relevant information, and decides whether or
not it can

    a) just deliver one of the cached entities
    b) make a conditional request on the next inbound server
    c) make an unconditional request on the next inbound server

The decision cannot be made by simple key-comparison, so the request
profile is not considered a key.

If (b) or (c) returns a new entity, the cache MUST store it in the
same way as the request was made (i.e., it already knows the entry
in the cache -- there is no replacement key).  The new entity replaces
one of the old entities if it has the same variant-id or content-location
and was generated at a later Date.  If the new entity has a 
content-location, the cache must mark as stale all other Request-URI
entries which refer to that content-location, but it is not a 
cache key (it is an entity key, internal to the cache DB operation).

For reasons of security, completeness, simplicity, and transparency,
the cache cannot serve a response received using one Request-URI to
a client requesting some other Request-URI, even when such would be
indicated by transparent negotiation.  Simply obeying that principle
removes most of the complexity that Koen is talking about.

Is this the only way to implement an HTTP cache?  No.
Is it the best way?  Not sure.
Is it something suitable for IETF standardization?  Not a chance.

Put it in a book, or an Informational spec, but keep it out of the
interface specification.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Friday, 26 April 1996 19:58:03 UTC