W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2003

RE: Changing etag and getlastmodified on move/rename

From: Lisa Dusseault <lisa@xythos.com>
Date: Mon, 11 Aug 2003 13:54:37 -0700
To: "'Julian Reschke'" <julian.reschke@gmx.de>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
Message-ID: <00f101c3604a$c6b1bfd0$f8cb90c6@lisalap>

> > Wouldn't the "getlastmodified" value change during this operation
> > as well?  I'm assuming that at the beginning /a/b and /a/c had 
> > different content, which is why the ETag had to changed when the 
> > MOVE caused the content /a/c to be overwritten with the content 
> > from /a/b.  If that's the case then the result of a GET to /a/c 
> > is different after the move, so the 'getlastmodified' must 
> also change.
> Most of the time yes, but not always: if /a/b and /a/c might 
> have had the same DAV:getlastmodified property before the 
> MOVE, in which case the date for /a/c may not change (one of 
> the reasons why ETags are better than dates).

The 'getlastmodified' property probably shouldn't be preserved across most MOVE operations.  Recall that the meaning of 'getlastmodified' isn't defined as the time that a user last made changes to the content of a resource.  Rather, it's the date at which the results of a GET request to that URL last changed.  That's because it's tied to the Last-Modified header definition in HTTP.

Consider the case where a MOVE operation overwrites an existing resource with different content.  Clearly the HTTP Last-Modified header value must now be set to the timestamp of the MOVE operation, because this operation invalidates previously cached copies of the destination resource.

Consider next the case where a MOVE operation creates a new resource with content from somewhere else.  Even though that content wasn't new content, it is new at that URL.  A client may get confused trying to synchronize a resource which didn't even exist before time T, yet its 'getlastmodified' or Last-Modified value is prior to time T.  I think the safest thing to do in this case is again to update the value to the timestamp of the MOVE operation.

If we want a property which instead tells us the last time a user made changes to the body of a file, we would have to define a new property which would happen to have the same value as 'getlastmodified' much of the time.  But the new property would probably be client writable so that a synchronizing or backup client could tell the server when the file was last changed.

Received on Monday, 11 August 2003 16:53:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:28 UTC