- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 20 Aug 96 12:07:45 MDT
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: 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.
Yes, this is correct. If the server is using the modification time
to create Etags which are encodings of that timestamp, then it is
possible for the server to tag them as "weak" or not based on your
algorithm.
That's why I wrote in
http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q3/0340.html
this:
a file modification timestamp T of any resolution R is only "weak"
during the period R+|E| after the file has been modified, where E
is a bound on clock skew. To make this more specific, suppose that
you know that
(1) file F was modified at time T
(2) the timestamp T has a resolution of R seconds
(3) the clock used to generate the timestamp T is at most E
seconds away from the clock used by the server to find out
the current time.
Then, between time T and time T+R+|E|, you would have to generate
an entity tag of the form
W/"encoding-of-T"
but after time T+R+|E|, you could generate an entity tag of the form
"encoding-of-T"
because you are now sure that you have not given out that tag for
a previous version of the resource.
see that URL for more details, including the issue of locking.
But a separate question arose regarding the use of Last-Modified
dates (i.e., the strings passed in a Last-Modified header, not
the opaque strings passed in an Etag header) in context where
a strong validator is required. And in that case, the server has
no way to tag the Last-Modified value as weak or strong, so the
rules in 13.3.3 are (probably) the best that we can do.
-Jeff
Received on Tuesday, 20 August 1996 12:16:46 UTC