- From: Julien Pierre <jpierre@netscape.com>
- Date: Wed, 02 Feb 2000 17:16:51 -0800
- To: http-wg@cuckoo.hpl.hp.com
- Message-ID: <3898D702.2B022EE6@netscape.com>
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