Last-Modified data doesn't reflect file modification date

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 UTC