If-Modified-Since implementation question

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

Received on Wednesday, 2 February 2000 17:28:28 UTC