- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Fri, 20 Jul 2012 07:25:55 +0000
- To: Mark Nottingham <mnot@mnot.net>
- cc: HTTP Working Group <ietf-http-wg@w3.org>
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