- From: Julien Pierre <jpierre@netscape.com>
- Date: Thu, 03 Feb 2000 13:10:17 -0800
- To: "David W. Morris" <dwm@xpasc.com>
- Cc: http-wg@cuckoo.hpl.hp.com
- Message-ID: <3899EEB9.219D4EAA@netscape.com>
David, "David W. Morris" wrote: > On Wed, 2 Feb 2000, Julien Pierre wrote: > > > > > 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 ? > > 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. 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. -- for a good time, try kill -9 -1
Received on Thursday, 3 February 2000 13:19:55 UTC