W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: Date in If-modified-since header

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 15 Oct 96 15:20:46 MDT
Message-Id: <9610152220.AA06827@acetes.pa.dec.com>
To: Ari Luotonen <luotonen@netscape.com>, http-wg mailing list <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1773
> 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 :-)

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:20 UTC