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

Re: If-Modified-Since and forged dated

From: Larry Masinter <masinter@parc.xerox.com>
Date: Wed, 16 Aug 1995 19:38:27 PDT
To: sjk@amazon.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <95Aug16.193834pdt.2763@golden.parc.xerox.com>
I think there's a misunderstanding somewhere.

I suggested:
>> * A server encountering a file with a modification date in the future
>>   (according to the server's current time) should not send the future
>>   'last-modified' date.

and Shel Kaphan rejoindered lengthily, but I will extract:

> Expecting all servers to be within .0000X seconds of UTC seems just a
> bit Draconian to me.

Clock drift is not an issue here. Suppose the server or file system
clock is 20 minutes off in such a way that file dates might be 20
minutes in the future. Then there's a 20 minute window where newly
written files might be sent without a 'last-modified' date. After that
point, even though the clock is off a bit, they'll still be cached.
Nothing in the suggestions I made requires 'all servers to be within
.0000X of UTC'.

> (Are there even NTP implementations for Mac and Windows? If so, how
> many Mac or PC based web sites run them?)

I confess I don't know about Windows NTP, though I see it in the list
of things supplied with a couple of 'commercial web services'.
'Network Time' is easy to install and use for Macs.

> Date errors are the server's to fix, but I don't agree that clock
> drift should be punished.

Clock drift isn't punished. Being a year off might be. Even being an
hour off just means that files less than an hour old won't get cached,
but... time flies! An hour later, they will be.

>> * A proxy or cache shouldn't save a document with a future last-modified.
> Disagree. Same reasons as above.

Your reasoning apparently has the same flaw here.
Received on Wednesday, 16 August 1995 19:39:59 UTC

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