W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

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

From: David Booth <david@dbooth.org>
Date: Tue, 31 Jan 2012 17:18:21 -0500
To: Julian Reschke <julian.reschke@gmx.de>
Cc: ietf-http-wg@w3.org
Message-ID: <1328048301.2250.20721.camel@dbooth-laptop>
On Tue, 2012-01-31 at 22:08 +0100, Julian Reschke wrote:
> On 2012-01-31 19:31, David Booth wrote:
> > Not sure where to ask this, but . . .
> >
> > Has there been any thought or discussion of allowing the Last-Modified
> > header to (optionally) carry more precision that one second, for the
> > benefit of clients that wish to reliably detect when a server has
> > changed its output faster than once per second?  For example:
> >
> >    Last-Modified: Fri, 27 Jan 2012 20:21:10.011483 GMT
> I don't think this has been mentioned so far.
> > Note that it is possible to get around the current one-second limitation
> > using ETags, but it would be nice if finer precision could be indicated
> > directly in the Last-Modified header.
> Not sure what this buys you compared to an ETag?

In building a high-speed distributed system based on HTTP, I am finding
myself forced to use the ETag to encode a high-resolution last modified
time, which seems silly given that there is already a Last-Modified
header.  If I do everything with the ETag instead of the Last-Modified
header, then what's the point of having the Last-Modified header?  Well,
it turns out that for many other purposes it is convenient to have a
header that you know is a time (rather than an opaque server-generated
string).  This means that servers must set *both* the Last-Modified
header *and* the ETag if one wishes to indicated a high-resolution last
modified time.  But since the ETag is an opaque string, the clients will
not know that it is actually a high-resolution last modified time
without some non-standard prior agreement.  Thus, in situations where
high-resolution last-modified times are relevant, it would simplify both
servers and clients if the Last-Modified header could optionally carry
fractional seconds.

> > I'm assuming that this is out of scope for the current HTTPbis charter,
> > so I'm mostly asking this regarding potential future work.  But the
> > "Potential Work" page is almost empty, and hasn't been updated in 16
> > months:
> > http://trac.tools.ietf.org/wg/httpbis/trac/wiki/PotentialWork
> >
> > Has this been discussed?  If not, does the suggestion belong?
> I think the Wiki page is a good pace to record this as proposal.

Thanks, I've added it:

David Booth, Ph.D.

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.
Received on Tuesday, 31 January 2012 22:18:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC