RE: Changing etag and getlastmodified on move/rename

> > 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 UTC