- From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
- Date: Tue, 15 Oct 1996 14:29:19 -0700
- To: Ari Luotonen <luotonen@netscape.com>
- Cc: http-wg mailing list <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
> I have been brought up the issue of the date string used in the
> If-modified-since header. Current practice is to use the
> Last-modified header, and given clock skew, it's also the only
> foolproof way to do IMS requests. Could the wording in the spec be
> changed to reflect that, and eliminate this source of data
> incorrectness? Basically, change the semantics of "If-modified-since"
> be "In-not-equal-last-modified".
No. While exact cache comparison is the most frequent use of IMS,
it is not the only use, and sending an IMS value containing the Date
(instead of the Last-Modified) field value is normal and accepted practice.
The server will not adequately support HTTP clients if it does a strict
equality check.
> Netscape servers and proxy were changed to use an equality check,
> because there were cases, with older software, incorrectly set
> timezones or machine times and daylight savings times where the dates
> would be off and stale data would be rendered up-to-date.
That is the wrong fix. The right fix is described under how to deal
with last-mod dates which are later than the server's date (the remote
filesystem problem) and how to interpret IMS dates which are later
than the server's date (the bad clock problem). Additional opaque
validation can be achieved by using the Etag and If-None-Match header fields.
...Roy T. Fielding
Department of Information & Computer Science (fielding@ics.uci.edu)
University of California, Irvine, CA 92697-3425 fax:+1(714)824-4056
http://www.ics.uci.edu/~fielding/
Received on Tuesday, 15 October 1996 14:38:56 UTC