- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 04 Sep 96 18:29:35 MDT
- To: peterson@austin.ibm.com
- Cc: fielding@avron.ics.uci.edu, frystyk@w3.org, hallam@w3.org, jg@w3.org, mogul@pa.dec.com, timbl@hq.lcs.mit.edu, www-talk@w3.org, Larry Masinter <masinter@parc.xerox.com>
The current scheme, as I understand it, requires that every reference
to a page be checked to see if it is out-of-date. Since a page may
change at any time (but probably won't), we assume that a reference by
a client to the page in the proxy will require the proxy to check with
the server to see if the page is out of date (either with a HEAD
request or a GET if-modified-since request).
Just to clarify: HTTP does NOT require every reference to be checked
over the network (i.e., with the origin server). Only if the cache
entry has passed its expiration time (or is explicitly marked with
a directive such as "Cache-control: must-revalidate") does the protocol
expect a cache to check with the origin server.
When a cache entry is "fresh" (e.g., its age has not exceeded the
server's specified maximum age), the proxy normally should NOT check
with the server. (There are circumstances in which a user who
mistrusts the cache's algorithms may insist on checking, but we don't
expect this to be the normal case.)
As for callbacks: I'm a fan of callbacks in distributed systems. (See
my papers on "Spritely NFS", which is basically adding Sprite-like
callbacks to the NFS protocol). But it is not possible to add
callbacks to HTTP without a major redesign of the protocol, and
even if we could do that, we might still run into complex issues
related to access control and network reliability. (Most of the
hard work on Spritely NFS was dealing with network failures.)
It's almost certainly still an open research problem, and it would
be premature to try to insert a callback mechanism into the IETF's
HTTP standard(s).
-Jeff
Received on Thursday, 5 September 1996 13:16:39 UTC