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

From: David Booth <[email-masked]>
Date: Tue, 31 Jan 2012 13:31:51 -0500

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

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.

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?

Thanks

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 31 Jan 2012 22:08:19 +0100

>    Last-Modified: Fri, 27 Jan 2012 20:21:10.011483 GMT

I don't think this has been mentioned so far.

> directly in the Last-Modified header.

Not sure what this buys you compared to an ETag?

> Has this been discussed?  If not, does the suggestion belong?

I think the Wiki page is a good pace to record this as proposal.

Best regards, Julian

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 01 Feb 2012 10:41:38 +1300

> Not sure what this buys you compared to an ETag?

the ability to compare against other previous Last-Modified headers.  
That allows the client to know whether a version supercedes another, 
rather than having to defer to the server.

I'd be in favour.

It would have been nice if the definition for ETag could have allowed 
for comparison (required monotonic increase), such as a revision number.

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 31 Jan 2012 22:47:16 +0100

> rather than having to defer to the server.

It might break recipients.

Anyway: please go ahead and add it to the Wiki so once we get there we 
have food for thought.

> for comparison (required monotonic increase), such as a revision number.

Well, that would have made other cases harder (I've seen UUIDs used as 
ETags).

---

From: David Booth <[email-masked]>
Date: Tue, 31 Jan 2012 17:18:21 -0500

> 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 think the Wiki page is a good pace to record this as proposal.

Thanks, I've added it:

-- 
David Booth, Ph.D.
http://dbooth.org/

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 01 Feb 2012 12:23:01 +1300

> In building a high-speed distributed system based on HTTP, I am 

Just to throw a few spanner in the general direction of the works...

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

??

Also note that for this to work it affects representation in Date:, 
If-Modified-Since, Last-Modified, Expires, Age and several proprietary 
and experimental headers including If-Unmodified-Since, Date-Created, 
Date-Updated. Possibly others in HTTP extension RFCs I've not had to 
deal with.

It will also have to account for conversion loss when travelling over 
HTTP 1.0/1.1 hops, and conversion from non-HTTP protocols 
representations.

> servers and clients if the Last-Modified header could optionally 

I agree this is a useful change. If the hurdles above can be worked 
around in a satisfactory way.

I vote for changing to UTC numeric TZ offsets and dropping the day 
representation as part of the change. We may as well go for something 
more optimized for machine processing.

AYJ

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 01 Feb 2012 00:29:23 +0000

>rather than having to defer to the server.

Me too.

But there are necessary consequential changes:
	Expires: headers
	Cache-Control: age fields.
	Age: header.
Possibly more.

Have anybody tried sending such dates to see how much code it breaks ?

I would fear a lot of both clients and servers would choke on it.

-- 
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: David Morris <[email-masked]>
Date: Tue, 31 Jan 2012 18:06:47 -0800 (PST)

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),

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.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 01 Feb 2012 04:00:11 +0100

>I would fear a lot of both clients and servers would choke on it.

When writing draft-hoehrmann-date-parsing I looked a bit into that and I
am quite sure this would break very many parsers (I never announced that
draft, nobody ever pointed out the bugs in it, and I do not intend to do
anything with it at this point).
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/