- 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
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