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.

Lisa
Received on Monday, 11 August 2003 16:53:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:04 GMT