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

On 2012-01-31 22:41, Adrien de Croy wrote:
>
>
> On 1/02/2012 10:08 a.m., 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?
>
> 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 might break recipients.

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

> It would have been nice if the definition for ETag could have allowed
> 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).

Received on Tuesday, 31 January 2012 21:47:59 UTC