Re: Increasing precision of Last-Modified header to allow sub-second granularity?

On Wed, 1 Feb 2012, Amos Jeffries wrote:

> 
> What type of sub-second resolution do you expect to work over a protocol with:
>  * seconds of RTT,
>  * clock skew scaled from whole seconds up to days (a week or so skew between
> two "synced" server behind one LB is not uncommon),
>  * middleware conversion to and from whole seconds,
>  * surrogate generated Date headers

What I would expect is that a server could opt to provide a last-modified 
date with subsecond resolution as an atomic update marker which has
a well specifed ordering for comparison. Book keeping for if-modified
tests would be simpler at the server and clients.

RTT, clock skew, etc. don't matter as the date provided would be 
associated with the resource and the same date used everywhere it is 
stored. Like windows systems today and unix systems with the proper
flags ... yeah I know fractional sections are generally not kept
by the file system.

Middleware issues and surrogates exist for ETag generation as well. 
Frankly, if the surrogate is generating the date header, the precision
increase is a moot point.

And clocks CAN be synced if a server farm is using the extended date.

Of course, it doesn't just plug in. dah! There would be a ripple
effect as others have noted. Probably can't be in HTTP/1.1 but
might be useful for some future update.

Received on Wednesday, 1 February 2012 02:07:28 UTC