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