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

David Booth <david@dbooth.org> Tue, 31 January 2012 18:33 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAEA11E8104 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 31 Jan 2012 10:33:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkMZyYJzDRoe for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 31 Jan 2012 10:33:25 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6872A11E80FF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 31 Jan 2012 10:33:25 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1RsIVy-00080q-8v for ietf-http-wg-dist@listhub.w3.org; Tue, 31 Jan 2012 18:33:10 +0000
Received: from aji.keio.w3.org ([133.27.228.206]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <david@dbooth.org>) id 1RsIVH-0007zk-28 for ietf-http-wg@listhub.w3.org; Tue, 31 Jan 2012 18:32:27 +0000
Received: from relay00.pair.com ([209.68.5.9]) by aji.keio.w3.org with smtp (Exim 4.72) (envelope-from <david@dbooth.org>) id 1RsIVA-0003Sk-V6 for ietf-http-wg@w3.org; Tue, 31 Jan 2012 18:32:25 +0000
Received: (qmail 22389 invoked from network); 31 Jan 2012 18:31:52 -0000
Received: from 98.118.64.3 (HELO ?192.168.10.110?) (98.118.64.3) by relay00.pair.com with SMTP; 31 Jan 2012 18:31:52 -0000
X-pair-Authenticated: 98.118.64.3
From: David Booth <david@dbooth.org>
To: ietf-http-wg@w3.org
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 31 Jan 2012 13:31:51 -0500
Message-ID: <1328034711.2250.16605.camel@dbooth-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7
X-W3C-Scan-Sig: aji.keio.w3.org 1RsIVA-0003Sk-V6 14285e80dcfabe628bc0c5f3124be5b2
X-Original-To: ietf-http-wg@w3.org
Subject: Increasing precision of Last-Modified header to allow sub-second granularity?
Archived-At: <http://www.w3.org/mid/1328034711.2250.16605.camel@dbooth-laptop>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/12272
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1RsIVy-00080q-8v@frink.w3.org>
Resent-Date: Tue, 31 Jan 2012 18:33:10 +0000

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.