W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: Entity Tags

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
Message-Id: <96Aug19.175604pdt."168963"@nebula.parc.xerox.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1417
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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:18 UTC