- 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
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: http://trac.tools.ietf.org/wg/httpbis/trac/wiki/PotentialWork -- David Booth, Ph.D. http://dbooth.org/ 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