RE: Changing etag and getlastmodified on move/rename

On Sunday, 08/17/2003 at 12:51 ZE2, "Julian Reschke" 
<nnjulian.reschke___at___gmx.de@smallcue.com> wrote:
> I think the only safe way to respect RFC2616 semantics is to require 
that after 
> a COPY/MOVE, DAV:getlastmodified is set to the current date.
>
> 2) I also agree that this is likely to cause complaints from people who 
> actually want a time stamp for *resource* modifications. 

So it sounds like getlastmodified becomes a 100% live property that
really isn't a property of the resource, but instead is a property of the 
URL.   It won't be setable and it's up to the server to maintain some 
sort of database to track if the mapping of any given URL has 
changed since some other point in time or if the resource itself has 
been modified.  Is this doable?  Would a server tend to do this 
recursively?  ie, Every binding has an age and the URL can be no
older than any of the bindings that are currently traversed to
reach that URL?  Or is there a better way to maintain the semantics 
that you propose we maintain?

Do servers already do this sort of thing?  If I mv a resource in to
a directory served by Apache, does it use the date the file system
lists, or something newer?

J.

Received on Sunday, 17 August 2003 16:32:23 UTC