Re: Fwd: Our old friends, weak ETags

In message <1A5726B2-376F-4C64-8F87-936C928A8224@mnot.net>, Mark Nottingham wri
tes:
>Bruce Perens isn't on the mailing list, so forwarding (a dup may occur =
>when W3C staff see it):

>> I use ETag because of an insufficiency in RFC 2616 dates: their 
>> resolution is one second. Updates to entities at sub-second intervals 
>> are possible and would result in entities with the same Last-Modified 
>> date.

Varnish users have raised similar concerns, because seconds are
awfully big for modern computers.

Time-wise there are some pretty nasty representation and efficiency
issues which I won't bore you with the full story about now, (I will
be happy to do so once we produce the normative text.)

The short story is:  However we decide to do it, we have to represent
the fractional part of the second as a true fraction in the radix.

For a string representation, that means a suffix of a period and 
digits without any unit: .9, .99, .999, .9999, .99999 ... are
all valid and increasingly late timestamps.

For binary, the field will be a (most likely be a 16 bit wide)
binary fraction so that the unit becomes 1/65536th of a second,
and
	0x8000 = 0.5 second
	0xc000 = 0.75 second
etc.

What we should absolutely *not* do, under any circumstanses, is
fixed width decimal count of milliseconds ("000" ... "999") or
binary multiradix nightmares like struct timeval/timespec.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Friday, 20 July 2012 07:26:23 UTC