Re: Improving If-Modified-Since

HTTP servers and caches are expected to keep correct time. Clients are
generally not. A well-written 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; if that were to
happen anyway, a proxy or cache shouldn't save a document with a
future last-modified.

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.

With this scheme, any file whose date was set early (written in 1970)
can be updated by setting the modify-date to the current time. Any
file whose date was set far in the future will not have been cached.
In the infrequently occuring case where a document is actually
modified at 12:04 and sent out at 12:05, but the cache's clock is
slightly misadjusted to think it is 12:03, a document that could be
cached will not be; the next time the document is requested, though,
the modification date will still be 12:04 and caching will happen.

With these simple conventions (which are just good implementation
conventions for the current protocol) we don't need to change the
protocol or add any heuristics about future or past dates.

Received on Tuesday, 15 August 1995 16:09:01 UTC