Subject: question about MOVE and COPY overwriting folders

From: John Reese <[email-masked]>
Date: Fri, 17 Dec 2004 15:23:01 -0800

Good afternoon, WebDAV wg.  I have a question about the interpretation
of RFC 2518 -- I hope this is the right place to post it.  If there's
a better list, please let me know, and I subjunctively would apologize
for posting here.

I'm implementing a DAV server for a commercial product that exposes
its content through various protocols, of which DAV is only one. 
There is some concern that the DAV semantics for MOVE and COPY with
the overwrite header set to T are too dangerious for our repository...
if the destination is a collection, it may be dangerous to do the
equivalent of a depth-infinity DELETE before the MOVE or COPY, as
section 8.8.4 and 8.9.3 dictate, because resources within a collection
may have additional metadata, like version histories and so forth, as
well as the equivalent of dead properties (although they won't be
exposed as such through our DAV server in the first release).

So, I have two questions:

1. given that overwriting a collection can have repurcussions for dead
properties and so forth in general, why are MOVE and COPY defined as
deleting the collections instead of (for example) a recursive
per-resource overwrite that would retain properties on corresponding
resources and remove those resources that were not in the source
folder?

2. would refusing to service MOVE or COPY requests, regardless of the
value of the Overwrite header, when the destination is a non-null
collection resource (responding, for example, with a 405 Method Not
Allowed to such requests), be compliant with the RFC, or would it
conflict with the rules in section 8.8.4 and 8.9.3?

Thanks.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 17 Dec 2004 23:49:57 -0500

You should feel free to fail any operation that you feel is inappropriate
for your repository.  WRT the semantics of depth COPY, RFC-3253 modifies
the definition of COPY to indicate that it overwrites the existing 
resource,
rather than deleting it first (for the reasons that you identify), so you
should feel free to implement COPY that way.  On the other hand, MOVE
with overwrite does delete the destination, so you should fail that 
operation
if you don't like that behavior.

Cheers,
Geoff