RE: Changing etag and getlastmodified on move/rename

Since RFC2616 explicitly states that a server may use
the file system last-modified dates for the value of the
Last-Modified header, I suggest that we also add words
to the effect that:

"To deal correctly with servers that use the native
repository last-modified times which are not updated by a MOVE,
a conservative caching mechanism will store the results of the previous
getlastmodified date, and only assume the cache is valid if
the current getlastmodified date is equal to the stored
getlastmodified date".

Cheers,
Geoff


w3c-dist-auth-request@w3.org wrote on 08/17/2003 10:08:50 PM:

> 
> I agree with all of this.  I have no problems putting an optional 
> modificationdate in RFC2518bis if we can get agreement quickly 
> because I think it could be implemented extremely quickly in several
> implementations. 
> 
> Lisa
> 
> > -----Original Message-----
> > From: Julian Reschke [mailto:julian.reschke@gmx.de] 
> > Sent: Sunday, August 17, 2003 3:51 AM
> > To: Lisa Dusseault; 'Julian Reschke'; 'Webdav WG'
> > Subject: RE: Changing etag and getlastmodified on move/rename
> > 
> > 
> > Lisa,
> > 
> > you are right that WebDAV absolutely can't overrule what 
> > RFC2616 (HTTP/1.1) says about the Last-Modified header and 
> > caching. Thus
> > 
> > 1) We probably should clarify the COPY/MOVE behaviour. 
> > Currently the draft says:
> > 
> > "COPY/MOVE behaviour: This property value is dependent on the final 
> >             state of the destination resource, not the value of the 
> >             property on the source resource. It MUST NOT be set in 
> >             PROPPATCH during a cross-server copy. "
> > 
> > How is the previous DAV:getlastmodified date of the 
> > destination resource relevant?
> > 
> > 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. A proper way to address this may be to define 
> > a new optional property (if we make it optional, we may be 
> > able to get it into RFC52518bis), for instance:
> > 
> >    Name:    modificationdate 
> >    Namespace:   DAV: 
> >    Purpose:     Records the time and date the resource was modified. 
> >    Value:   date-time 
> >    COPY/MOVE behaviour: This property value SHOULD be kept during a 
> >             MOVE operation, but is re-initialized when a resource is 
> >             created with a COPY. It should not be set in a 
> > remote COPY. 
> >    Description: The creationdate property should be defined 
> > on all DAV 
> >             compliant resources.  If present, it contains a timestamp 
> >             of the moment when the resource was last modified 
> > (i.e., the 
> >             moment when content and/or propertoes last changed).
> >             This property is live and 
> >             protected. The Internet date-time format is defined in 
> >             [RFC3339], see the ABNF in section 5.6. 
> > 
> >    <!ELEMENT modificationdate (#PCDATA) > 
> > 
> > Julian
> > 
> > 
> > --
> > <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 
> > 
> > 
> 
> 
>