W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: Sections 13.2.4 and 13.3.3

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Mon, 03 Jun 96 12:57:25 MDT
Message-Id: <9606031957.AA03549@acetes.pa.dec.com>
To: Ben Laurie <ben@algroup.co.uk>
Cc: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/753

    Note that neither of these calculations is vulnerable to clock
    skew, since all of the information comes from the origin server.


    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.

Received on Monday, 3 June 1996 13:10:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC