W3C home > Mailing lists > Public > www-jigsaw@w3.org > November to December 1996

Last-Modified data doesn't reflect file modification date

From: Anselm Baird_Smith <abaird@www43.inria.fr>
Date: Thu, 14 Nov 1996 11:28:08 +0100 (MET)
Message-Id: <199611141028.LAA13768@www43.inria.fr>
To: Neal McBurnett <nealmcb@bell-labs.com>
Cc: www-jigsaw@w3.org
neal@bighorn.dr.lucent.com writes:
 > I notice that the HTTP header "Last-Modified:" for an ordinary html
 > file doesn't reflect the modification date in the file system, the way
 > it does with most other servers.

Correct, that's a feature in fact...

 > It does seem to remain stable at least for a while after
 > the first time a document is retrieved (perhaps reflecting the
 > time that the cached resource was created?).  But I worry that
 > something might cause the date to change even though the same
 > response was sent at a later time.

That's exactly the problem this "feature" solves: if *anything* in the
reply is to change, then the last modified date of the resource will
change. Typicall example is changing the content-type attribute of a
resource: this will (properly) change the Last-Modified date, even
though the undderlying file itself hasn't change.

 > Real dates are often interesting to the user (and can be seen via, e.g.,
 > the View/Document_Info menu item in Netscape).  Stable dates are
 > critical for caching to be effective.

Agreed, and that's the purpose of this feature (cache will work
correctly even if you change the content-type of a resource, for
example)

 > Would it be possible to get Jigsaw to always serve real file-system dates
 > when appropriate?

Do you still think it's needed ?

Anselm.
Received on Thursday, 14 November 1996 05:28:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 April 2012 12:13:25 GMT