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

Re: Entity Tags

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 20 Aug 96 12:07:45 MDT
Message-Id: <9608201907.AA18807@acetes.pa.dec.com>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:08 EDT