- 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