Subject: If-Modified-Since implementation question

From: [email-masked] (Julien Pierre)
Date: Wed, 02 Feb 2000 17:16:51 -0800

Quoting from 14.25 :

"14.25 If-Modified-Since

   The If-Modified-Since request-header field is used with a method to
   make it conditional: if the requested variant has not been modified
   since the time specified in this field, an entity will not be
   returned from the server; instead, a 304 (not modified) response will

   be returned without any message-body.

<snip>

      Note: When handling an If-Modified-Since header field, some
      servers will use an exact date comparison function, rather than a
      less-than function, for deciding whether to send a 304 (Not
      Modified) response. To get best results when sending an If-
      Modified-Since header field for cache validation, clients are
      advised to use the exact date string received in a previous Last-
      Modified header field whenever possible. "

Consider the following case :
a) user browses a web site, gets a document
b) server returns the date of the document, and a Last-Modified : xxx

The next day, the document is updated with a different version, and an
older date, yyy.

c) user browses the web site, gets a document again, with
If-Modified-Since : xxx
d) server does a "less than" comparison and returns 304

In this case the user just does not see the latest document, unless he
disables the caching.
But the situation could be much worse if byte ranges are involved. The
browser could end up with a mix of several documents!

Therefore, the servers that are doing an exact date comparison, as
suggested in the note, are doing the only safe thing.
Doing a "less than" type of comparison will cause problems when files
get rolled back to older versions.
If-Unmodified-Since suffers from the same flaw and is equally dangerous
.

Was the possibility of files being rolled to older versions just
overlooked in the HTTP spec ?
If not, how are these cases supposed to be handled ?

--
for a good time, try kill -9 -1

---

From: "David W. Morris" <[email-masked]>
Date: Wed, 2 Feb 2000 20:34:07 -0800 (PST)

> If not, how are these cases supposed to be handled ?

Overlooked ... no, when the file is changed is must have a newer last
changed date ... the content of the web server changed even if the file
contains an older version of the content.  ETags were invented as the full
solution.

Dave Morris

---

From: [email-masked] (Julien Pierre)
Date: Thu, 03 Feb 2000 13:10:17 -0800

David,

"David W. Morris" wrote:

> contains an older version of the content.

That's all very good in theory.
In practice, some file systems on some operating systems (for example FAT on
Windows NT) do not preserve the last-written, access or creation date. They
only keep a file date. Therefore, it is not feasible for the web server to
tell that the document was indeed modified with an older date.

If it is still running, the daemon file cache could conceivably monitor the
dates on all the files and notice that some were rolled back to an older date.
This would be a very expensive operation, and the information would be lost if
the server is shut down, as server caches are normally not persisted. It would
also be subject to limitations of the cache size - you don't want to cache
prior date information for all files that were served, because your cache
cannot use an unlimited amount of RAM. The much easier solution is to do an
date equality test instead of less than.

> ETags were invented as the full
> solution.

Yes, they solve the problem in fact. But most of today's browsers don't use
it, and they will be around for a while. A new HTTP server still has to be
able to work with them.