Subject: Re: Our old friends, weak ETags

From: "Adrien W. de Croy" <[email-masked]>
Date: Fri, 20 Jul 2012 05:22:41 +0000

Hi Bruce, thanks for your answer.. but is this _weak_ ETags or just 
ETags in general?

Regards

Adrien

------ Original Message ------
>----------------------------------------------------------------------------
>
>Hi Adrien,
>
>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. To be pedantically resolution-independent, I convert the date/time
>to a string representation of a ratio. It's presently the number of
>nanoseconds since the epoch. I encode that and an entity serial number
>in the ETag.
>
>If HTTP dates are extended to have sub-second resolution, I will
>probably be able to do without ETags.
>
>    Thanks
>
>    Bruce
>
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 20 Jul 2012 15:25:04 +1000

Bruce Perens isn't on the mailing list, so forwarding (a dup may occur when W3C staff see it):

--
Mark Nottingham   Systems Architect, Cloud Standards and APIs
[email-masked]    http://www.mnot.net/

--
Mark Nottingham   http://www.mnot.net/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 20 Jul 2012 07:25:55 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:
>Bruce Perens isn't on the mailing list, so forwarding (a dup may occur =
>when W3C staff see it):

>> 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
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 20 Jul 2012 09:50:20 +0200

On Jul 20, 2012, at 09:25, Poul-Henning Kamp wrote:

> binary

See also RFC 5905 section 6.

Grüße, Carsten

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 20 Jul 2012 07:58:22 +0000

In message <[email-masked]>, Carsten Bormann writ
>See also RFC 5905 section 6.

Yes.

Although I think going full NTP is overkill, in particular because
timestamps tend to have very high entropy in the lower bits.

I think chosing a 16bit fraction will last us 20 years, but more
importantly, expanding a 16bit fraction to 32bits is just a matter
of stick on more bits, whereas a 16bit count of milliseconds is
a nightmare to extend.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 20 Jul 2012 10:22:34 +0200

On Jul 20, 2012, at 09:58, Poul-Henning Kamp wrote:

> milliseconds

Indeed, using milliseconds for anything is a "protocol smell".

If the resolution of milliseconds is about right for your needs, use mibiseconds (1/1024 s).

But this is off-topic for HTTP dates, for which mibiseconds are too long.
(And sorry for the Java guys :-)

Grüße, Carsten