Re: If-Modified-Since and forged dated

Sorry to be sending so much mail today -- but somehow the discussion
seems to have come close to certain areas of interest, so...

James Pitkow writes:
	...

 > This along with the below modified guidelines for behavior (originally from
 > <95Aug16.102012pdt.2763@golden.parc.xerox.com> from "Larry Masinter"):
 > 
 > * 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.
 > 

I agree that origin-servers should behave this way, and should log
such errors so the operators can correct the situation.  However I
think that intermediate proxies should simply pass on what they get
from the origin server, since *it need not matter to them*.  They also
should also save whatever date the upstream server says.  Furthermore,
when they issue a GET-IMS, they'd better use the date the upstream
server last claimed, even if it was in "the future" according to the
downstream server, or else they might not get the appropriate 304 they
could otherwise reasonably expect to get. Since downstream clients may
also wish to use last-modified dates to generate GET-IMS requests of
their own, that is why it should be passed on.  Expecting all servers
to be within .0000X seconds of UTC seems just a bit Draconian to me.
(Are there even NTP implementations for Mac and Windows? If so, how
many Mac or PC based web sites run them?) Building in magic time
thresholds that are "close enough" seems like a kluge.  And if a
server is just way off and can't interpret GET-IMS requests correctly
because of its own error generating last-modified, that's a local
problem.  Server software should, however, log GET-IMS requests where
the date is in *its* future, as it probably indicates a problem.

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

 > * Servers ought to be able to either precompute checksums periodically or 
 >   generate them on the fly, independent of the desires of proxies or caches.
 > 
Agreed.

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

 > * A client and any proxies along the way should remember the exact
 >   last-modified (to the second) with which the document was delivered,
 >   no approximations, and independent of any local time settings. The same 
 >   applies to size and checksum information if so desired.
 > 
Agreed.

 > Jim.
 > 
 > 
--Shel

Received on Wednesday, 16 August 1995 19:04:17 UTC