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

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



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


AYJ

Received on Tuesday, 31 January 2012 23:23:30 UTC