W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2001


From: Clemm, Geoff <gclemm@rational.com>
Date: Mon, 16 Apr 2001 23:13:49 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B102B8FC16@SUS-MA1IT01>
To: WebDAV WG <w3c-dist-auth@w3.org>
   From: John Glavin [mailto:john@riverfrontsoftware.com]

   ... If you PUT a file to the server, the server will update
   getlastmodified.  The way that existing Windows applications
   synchronize files is to copy the file to the server and then set
   the modified time to match the existing modified time of the file
   that is say on the users hard disk.  This way when it next checks
   to see if the file is in synch it will just check the last modified
   property.  I know that DAV isn't specific to Windows or any file
   system in particular, but it would be nice if there was a way in
   DAV to allow existing file synchronization software to work.  A
   simple way to do this is to allow the getlastmodified property to
   be set.

Given the choice between having HTTP/1.1 caching work and having a
certain kind of Windows file synchronization work, I'd have to vote
for HTTP/1.1 caching (it is an HTTP protocol after all :-).

In particular, RFC 2616 says:

   An origin server SHOULD obtain the Last-Modified value of the entity
   as close as possible to the time that it generates the Date value of
   its response. This allows a recipient to make an accurate assessment
   of the entity's modification time, especially if the entity changes
   near the time that the response is generated.

So this says that it should be the server's idea of the current time,
not some client's idea of the time.

So it would be fine to allocate some new property value to mean
"file-system's idea of the time", but we shouldn't use getlastmodified
to do so, because the value of getlastmodified being synchronized with
the server's idea of the current date is required for the HTTP/1.1
If-Modified-Since header semantics.

Received on Monday, 16 April 2001 23:14:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:22 UTC