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

Amos Jeffries <> Tue, 31 January 2012 23:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF91411E807F for <>; Tue, 31 Jan 2012 15:24:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.046
X-Spam-Status: No, score=-10.046 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e3dU+8EOIj2a for <>; Tue, 31 Jan 2012 15:24:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 34EB111E8076 for <>; Tue, 31 Jan 2012 15:24:55 -0800 (PST)
Received: from lists by with local (Exim 4.69) (envelope-from <>) id 1RsN3B-0003P0-Uf for; Tue, 31 Jan 2012 23:23:45 +0000
Received: from ([]) by with esmtp (Exim 4.69) (envelope-from <>) id 1RsN2w-0003JW-Bx for; Tue, 31 Jan 2012 23:23:30 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1RsN2u-0000rZ-El for; Tue, 31 Jan 2012 23:23:30 +0000
Received: by (Postfix, from userid 33) id D054AE6FAC; Wed, 1 Feb 2012 12:23:01 +1300 (NZDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Wed, 01 Feb 2012 12:23:01 +1300
From: Amos Jeffries <>
In-Reply-To: <1328048301.2250.20721.camel@dbooth-laptop>
References: <1328034711.2250.16605.camel@dbooth-laptop> <> <1328048301.2250.20721.camel@dbooth-laptop>
Message-ID: <>
User-Agent: Roundcube Webmail/0.7.1
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1RsN2u-0000rZ-El f270fb43f76d8e89eebccfaf2716822d
Subject: Re: Increasing precision of Last-Modified header to allow sub-second granularity?
Archived-At: <>
X-Mailing-List: <> archive/latest/12284
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>
Resent-Message-Id: <>
Resent-Date: Tue, 31 Jan 2012 23:23:45 +0000

On 01.02.2012 11:18, David Booth wrote:
> 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

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 

> 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 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.