- From: Shel Kaphan <sjk@amazon.com>
- Date: Wed, 16 Aug 1995 15:33:10 -0700
- To: Lou Montulli <montulli@mozilla.com>
- Cc: Larry Masinter <masinter@parc.xerox.com>, bne@bne.ind.eunet.hu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Lou Montulli writes: > > You are forgetting that this only solves a third of the problem. > > It doesn't solve the problem of two dates being exactly the > same but the file has been modified, or the problem of a file getting > modified and having it's date set into the past. Date's alone > are not a strong enough versioning system. And don't try and tell me > that these don't happen. *I* won't try to tell you that these don't happen, though they seem to be evidence of bugs or human activity that it is not clear HTTP should try to correct for after the fact. I can't think of a reason for this happening other than someone or something changing a system clock or deliberately falsifying a modification date. In any case, it doesn't seem like the responsibility of a communication protocol to try to figure out what's "really" going on if a server is too lame to get it right for itself. The percent of the time that there is going a problem like this seems like it must be small, certainly not worth imposing additional overhead on the protocol to correct for, especially if that involves scanning whole files for checksums. They are as likely to happen as a file with > a date far forward, and these kinds of problems are happening all > the time. > > In addition to these other two problems, by restricting dates that > have been set far forward, you are in effect disabling caching for > these files. This is a far worse solution to adding a checksum. > But you don't really need either if you just treat this future date as an opaque thingamabob you only use for GET if-modified-since later. > lou > -- > Lou Montulli http://www.mcom.com/people/montulli/ > Netscape Communications Corp. --Shel Kaphan
Received on Wednesday, 16 August 1995 15:38:09 UTC