Re: More followups

Keith Ball writes:
 > > > 2. Is there a view on how locally-time-stamped data should have their
 > > >    Last-Modified GMT computed?  It's impractical to recreate the
 > > >    true original GMT time-stamp (as the timezone and daylight savings
 > > >    regime of the place of last modification is usually unknown).  Using
 > > >    the current GMT offset will result in the timestamp of some data
 > > >    jumping forwards or backwards an hour, twice a year, which could
 > > >    affect caching.
 > > 
 > > There are many views as to how this should be done, but none of them
 > > are within the realm of the HTTP protocol.  All that matters is that
 > > the date used within the protocol is GMT (UT).  How the date is obtained
 > > (and, in fact, what it means to be "modified") is entirely up to the
 > > application sending the object.
 > 
 > Doesnt the lack of a clear meaning of modification make this almost '
 > useless, except maybe for a matched pair of client and server that
 > have a common meaning.  It needs to reflect that either the content
 > as returned is different then previous to the date.  I could also 
 > reflect metainformation change, such as expiration updated.  But, I
 > think that is a little too nebulous.
 
Neither of the words `modified', `different', and `change' do define
what is actually meant by this field. And this is how it should be! It
does _not_ make it useless but merely take away the binding to the
date and time typically given by the file system. As somebody (sorry,
but I don't remember who) pointed out, a document can be generated
automatically on every request, however, this doesn't necessarily
indicate that the LM field should change value.

-- cheers --

Henrik Frystyk
frystyk@W3.org
+ 41 22 767 8265
World-Wide Web Project,
CERN, CH-1211 Geneva 23,
Switzerland

Received on Monday, 5 December 1994 22:08:54 UTC