Re: forwarding cache requests

"Roy T. Fielding" <fielding@simplon.ICS.UCI.EDU>
Errors-To: listmaster@www0.cern.ch
Date: Tue, 22 Mar 1994 10:08:03 --100
Message-id: <9403220103.aa23418@paris.ics.uci.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: fielding@simplon.ICS.UCI.EDU
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Roy T. Fielding" <fielding@simplon.ICS.UCI.EDU>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: forwarding cache requests 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 3742

Reinier Post writes:

> In my cache server ('Lagoon'), few of the provisions in the HTTP MIME header
> specifications are currently implemented, but I have already noticed the
> need for more headers.  To send information on the cache status of a document
> to the client, I leave the headers obtained from the remote source intact,
> and consider adding the following ones:
> 
> Cache-date: <date>
> Cache-last-refreshed: <date>
> Cache-last-modified: <date>
> Cache-via: <url> [, <url>]*
> 
> This provides: the time the document was served from the cache in answer
> to the present request, the time the document was last fetched into the
> cache, the time it was last fetched and found to be different from the
> previous version, and the sequence of URLs by which the document was
> subsequently fetched. ...

My first question is: why does the client need to see these headers?
In other words, what task do you want the client to do that cannot be
done without these headers?  I will assume for now that the only reason
is to support hierarchies of cache managers.

Assuming that, here is my opinion about the headers listed above,

Cache-date:
     is inappropriate -- the Date: header of the message should
     list the date/time in which the cache manager generated the
     HTTP message (as a whole) for delivery to the client (i.e. it
     should always be the current date/timestamp.

Cache-last-modified:
     should be Cache-last-updated: and should reflect the date/timestamp
     of last comparison with the original (i.e. the Date: header returned
     by the source document's HTTP server in that comparison).  Note that
     this should not be changed by cache managers more than once-removed
     from the origin.  This is because the act of checking the cache
     consistency with the original document is equivalent to getting a new
     copy of that document, but the act of checking cache consistency with
     a higher-level cache is only equivalent to copying that cache.

Cache-last-refreshed:
     is unnecessary given Cache-last-updated.

Cache-via:

> ...  This last header, which provides a comma separated
> list of URLs, is required in order for cache servers to break loops in chains
> of forwarded requests.  (Lagoon 0.11a now supports such forwarding, but it
> doesn't check for loops yet.)  The last URL in this sequence is always
> the URL of the present request (with the '#name' relative anchor suffix
> removed).  All headers are completely optional, of course.

I am not convinced that loops are possible. Could you give us an example
where a normal (non-psychotic) cache hierarchy could result in a loop?

> This only addresses the cache specific information added to the HTTP response,
> but there is a similar design problem with adding cache information to the
> request.  For example, the User-agent: and From: headers, are they supposed to
> be as sent by the client, or are they supposed to identify the cache mechanism
> sending the actual request?

>From the HTTP2 spec, I'd say that they should reflect the originator of the
request. I.e. if the request was caused in response to a client, then that
client User-agent:, From:, and Referer: headers should be passed on.  However,
if the request was caused by a periodic function of the cache manager, then
it should only include the User-agent: and From: identifiers corresponding to
the cache manager.

I would recommend that cache managers append their product/version tag
to the User-Agent: header, but that topic deserves its own message.


...Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                   (fielding@ics.uci.edu)
    <A HREF="http://www.ics.uci.edu/dir/grad/Software/fielding">About Roy</A>