Re: Date in If-modified-since header

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

Although I think, if I-M-S were used *only* for cache validation,
this might have been a better design that the one that we now have
for I-M-S, it may not be the way that all existing clients expect
the servers to behave.  That's why I insisted that the entity-tag
mechanism be entirely opaque, and I encourage Netscape to help the
installed base move to a caching scheme based on entity-tags.

And I basically agree with Roy that there may be other reasons
to use I-M-S, other than strict cache comparisons.  (As long as
people are clear on why they are using I-M-S in this way!)

However, as an "advice to implementors" kind of thing, I would
suggest that an HTTP client ought to act as if the If-Modified-Since
headers that it sends *for cache validation* are going to be
interpreted as "If-Modification-date-does-not-match-exactly".
In other words, an HTTP client ought to be careful to preserve
all of the accuracy in the Last-Modified date, rather than (perhaps)
playing games based on the official semantics of If-Modified-Since.

This might also avoid certain potential problems related to time
zone changes :-)

-Jeff

Received on Tuesday, 15 October 1996 15:31:24 UTC