Subject: Re: High-resolution timestamp in HTTP response header

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Nov 2012 12:34:36 +1100

On 15/11/2012, at 12:22 PM, Akon Dey <[email-masked]> wrote:

> Hi,
> 
> The current HTTP headers related to time have a time granularity of 1 second. This is fine when considering the update time of files on a UNIX filesystem on the HTTP-server but is insufficient when considering today's use cases where the resource is not limited to just files but data store objects or database columns.
> 
> I would like to propose that the granularity of the data fields support higher time granularity given we are in the process of specifying the next version of the HTTP protocol.
> 
> This will enable the use of HTTP to higher throughput "put if-unmodified-since X" type operations among other useful things.
> 
> I would be glad to elaborate the use cases in more detail.

Hi Akon,

HTTP's granularity of time is very intentionally one second, because the clock skew that is prevalent on the Internet as well as the delay introduced by latency mean that an finer granularity is effectively an attractive nuisance; Web developers will believe that there is a degree of control offered that is in fact not available.

Additionally, changing the syntax to allow it in a backwards-compatible way isn't practical; this would have to be done with new headers.

When HTTP/1.1 was created, it was recognised that one-second granularity wasn't adequate for some use cases, especially validation. That's why ETags (along with If-None-Match) were created, to allow arbitrary and server-controlled granularity for validation.

Cheers,

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