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

Re: Improving If-Modified-Since

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 15 Aug 95 11:00:57 MDT
Message-Id: <9508151800.AA06968@acetes.pa.dec.com>
To: James Pitkow <pitkow@cc.gatech.edu>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
    It seems like an obvious solution(??) is for the cache to throw out
    all timestamps greater than a given drift period from the current
    time.  If I told you I did something in the future, would you
    believe me?

I would suggest that any timestamp more than 1 second in the future
is suspect, and should be tossed.  Remember that when choosing
between "cache this" and "do not cache this", the latter is always
the safe choice.

    I seems to recall a paper on that measured network clock drift,
    though it is most likely not valid now with all the PCs out there.
    Anybody else recall this paper?  If so, we could get an empirical
    basis for drift.
    
Dave Mills has written numerous papers, most recently in Proc.
SIGCOMM '94 (which cites a number of his earlier publications).
If the hosts involved are
    o	running NTP
    o	synchronized to proper time standards
    o	using reasonably decent clock crystals
then it is not at all hard to synchronize clocks to within a few
milliseconds, even over the Internet.

It's quite likely that manufacturers of cheap systems cut corners on
the clock-crystal quality, and/or the managers of a server or proxy
have failed to configure NTP properly.  So in real life, the clocks
could be skewed in either direction.  This, however, is not something
that the HTTP spec should be perverted to deal with.

-Jeff
Received on Tuesday, 15 August 1995 11:06:25 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:24 EDT