RE: Changing etag and getlastmodified on move/rename

I agree that a WebDAV client would prefer that the Last-Modified header
(and the DAV:getlastmodified property) be based on the URL
(and therefore change on every MOVE) rather than be based on
the resource (and therefore not change on a MOVE), but 2616
explicitly states that a possible implementation of the Last-Modified
value is the file system modification time.  This is based on
the pragmatic observation that it would be prohibitively expensive
for a variety of WebDAV servers to modify (or supplement)
the last-modification semantics of their underlying repository
(which is resource based, not URL based).

Cheers,
Geoff

Lisa wrote on 08/11/2003 04:54:37 PM:

> 
> > > 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 17:08:53 UTC