- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Mon, 03 Jun 96 12:57:25 MDT
- To: Ben Laurie <ben@algroup.co.uk>
- Cc: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
13.2.4
Note that neither of these calculations is vulnerable to clock
skew, since all of the information comes from the origin server.
13.3.3
The arbitrary 60-second limit guards against the possibility that
the Date and Last-Modified values are generated from different
clocks, or at somewhat different times during the preparation of
the response.
These two statements seem to be at odds.
They are not at odds.
The statement in 13.2.4 applies to calculations of total
freshness lifetime (before comparison with the Age of a
response). This calculation is not vulnerable to clock skew,
because the origin server declares its intentions unambiguously.
The statement in 13.3.3 refers to an algorithm for deciding
if a Last-modified time is a weak or strong validator by comparing
it to a Date value. Since there is no straightforward way to
enforce a specified relationship between these two values, it
is possible that the implied causal relationship is wrong. For
example, if the file system used by the HTTP server is remotely
mounted from a NFS server with a skewed clock, the (NFS-based)
last-modified time will be wrong.
60 seconds is a somewhat arbitrary value, and an implementation is
not required to use this inference rule.
-Jeff
Received on Monday, 3 June 1996 13:10:41 UTC