RE: Changing etag and getlastmodified on move/rename

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Monday, August 11, 2003 7:38 PM
> To: 'Julian Reschke'; 'Webdav WG'
> Subject: RE: Changing etag and getlastmodified on move/rename
> 
> 
> 
> > It shouldn't. Also, the other combination can occur as well 
> > (ETag changes, but getlastmodified doesn't). This is because 
> > the ETag must be unique for all representations produced for 
> > a particular URL (+ variant-selecting headers), *not* the resource.
> > 
> > Consider:
> > 
> > /a/b with etag "1"
> > /a/c with etag "1"
> > MOVE /a/b -> a/c
> > 
> > The resulting ETag for "/a/c" MUST NOT be 1.
> > 
> 
> 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).

Seems that the HTTP caching (lastmodified and etag) aren't very compatible with WebDAV namespace operations.


--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Monday, 11 August 2003 14:41:09 UTC