forwarding cache requests
reinpost@info.win.tue.nl (Reinier Post)
Errors-To: listmaster@www0.cern.ch
Date: Mon, 21 Mar 1994 11:55:02 --100
Message-id: <199403211052.LAA11804@wsinis10.info.win.tue.nl>
Errors-To: listmaster@www0.cern.ch
Reply-To: reinpost@info.win.tue.nl
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: reinpost@info.win.tue.nl (Reinier Post)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: forwarding cache requests
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2644
You (Markus Stumpf) write:
>I'd like to propose some more infos:
>
>I am currently working on a caching/proxy only server.
>This would allow configuring of "forwarders", i.e. intermediate
>servers for a hierarchy of caching servers, read only access to caches
>and so on ...
>Therefor it'll be really nice to have some information about the update
>rate of the caching servers like:
>"File is up to date for me but I haven't checked for n minutes".
>
>Another problem for this topic:
>How do I specify Expires: for e.g. GIF files? Would I have to do this
>via server config files?
>
>We currently use a "Expires:" of about 14 days for GIFs, assuming
>most of them are icons, which change seldon, if not never.
>But with all the weather GIFs and coffee machines :) out there ...
>
> \Maex
>
>P.S. If you have any proposals what caching servers should be able to do,
> drop me a note ...
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. 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.
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?
Before I implement anything that's out of line, dear incrowd, please give
me some comments or suggestions for improvement.
--
Reinier Post reinpost@win.tue.nl
a.k.a. <A HREF="http://www.win.tue.nl/win/cs/is/reinpost/reinier.E.html">me</A>