- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Mon, 19 Aug 1996 17:56:04 PDT
- To: mogul@pa.dec.com
- Cc: akosut@nueva.pvt.k12.ca.us, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Isn't there some confusion about the issue of file modification dates
as etags? The possibility that the file might be updated more quickly
than the clock resolution doesn't matter, as long as the server never
sends a date that is the same as 'now'. As long as the modification
date is in the past, then you can use that date as a validator; even
if the file gets modified 100 times in a nanosecond, it doesn't matter
since the new times will be different than the time you sent before.
Here's how to write a safe server:
a) lock file from modifications
b) check last modification date compared to current time
c) if last modification date is the same as current time,
then wait one clock tick
d) send file with file modification date
e) unlock file
If you can't lock your files from modification while they're being
sent, you're already in trouble. (What if it's updated in place while
you're sending it??!?). The only alternative would be to copy the file
somewhere else (into memory, for example):
a) note modification date of file.
b) copy file somewhere else.
c) check that the file wasn't modified while you were copying it.
If it was, go back to (a). (If you do this too many times,
you might send an error message, since there's no reliable
way to save a file that gets updated more quickly than you can
copy it.)
d) send copy of file with original modification date
Received on Monday, 19 August 1996 18:01:58 UTC