Subject: WebDAV COPY/MOVE Question

From: "Hall, Shaun" <[email-masked]>
Date: Wed, 19 Apr 2000 17:29:25 +0100

Greetings,

I have a couple of questions regarding the WebDAV RFC 2518, specifically the
COPY (and MOVE) operations for collections. I'll just refer to the COPY
sections in the RFC, but Question 1) is applicable for MOVE as well.

Question 1) COPY (and MOVE) with infinite Depth:

a) Section 8.8.3:

i) 2nd para, 1st sentence states "A COPY of depth infinity instructs that
the collection resource identified by the Request-URI is to be copied to the
location identified by the URI in the Destination header, and all its
internal member resources...".

ii) 5th para, 2nd sentence states "When applied to members of the collection
identified by the Request-URI the value of the Destination is to be modified
to reflect the current location in the hierarchy." The example shows source
is /a, destination is /b, when copying /a/c/d, the destination is /b/c/d.

b) Section 8.8.8 Example of a COPY of a collection appears to perform in
principle the example in a) ii) above.

We interpret a) i) to mean that the source collection and its members are
copied to the destination.

Taking the RFC example in a) ii), i.e. the source is /a/c/d and destination
is /b. Possible outcomes we can think are:

c) Destination of /b/a and /b/c/d. Doesn't make a lot of sense.
d) Destination of /b/c/d i.e. no /b/a. Doesn't appear to meet a) i) because
the source collection /a is not copied.
e) Destination of /b/a/c/d. This is "logical", but doesn't match RFC
examples in a) ii) and b).

Side note, two implementations we've tested performed d) i.e. they appeared
to perform a) ii).

Our opinion is that e) should be correct, but obviously, our opinion could
be wrong (please correct us if we are).

However, neither the examples in the RFC as listed in a) ii) and b) appear
to meet 1) a) i) because the source collection itself is not copied.

Maybe our interpretation is wrong, but what exactly does the RFC mean?

Question 2) COPY with Depth 0

The RFC section 8.8.3 3rd para states that the collection and its properties
are copied, but no resources. We tested COPY with a Depth 0 using source of
/a to destination /d on two implementations. Both implementations tested did
not appear to copy the source collection. Our interpretation is that the
source collection /a should have been copied to the destination i.e.
resulting in /a/d.

Is our interpretation wrong ?

Regards

Shaun Hall
Xerox Europe
The opinions are my own and not necessarily those of my employer

---

From: Jim Whitehead <[email-masked]>
Date: Wed, 19 Apr 2000 13:12:25 -0400

Hal Shaum writes:
> I have a couple of questions regarding the WebDAV RFC 2518,
> specifically the COPY (and MOVE) operations for collections.
> I'll just refer to the COPY sections in the RFC, but Question
> 1) is applicable for MOVE as well.
>
> i) 2nd para, 1st sentence states "A COPY of depth infinity
> instructs that the collection resource identified by the
> Request-URI is to be copied to the location identified by
> the URI in the Destination header, and all its internal
> member resources...".
>
> ii) 5th para, 2nd sentence states "When applied to members
> of the collection identified by the Request-URI the value of
> the Destination is to be modified to reflect the current
> location in the hierarchy." The example shows source
> b) Section 8.8.8 Example of a COPY of a collection appears to
> perform in principle the example in a) ii) above.
>

That is correct.

> Taking the RFC example in a) ii), i.e. the source is /a/c/d and
> destination is /b. Possible outcomes we can think are:
>
> d) Destination of /b/c/d i.e. no /b/a. Doesn't appear to meet a) i)
> because the source collection /a is not copied.
> Side note, two implementations we've tested performed d) i.e.
> they appeared to perform a) ii).
>

Actually, d) is correct.

When writing the spec, the conceptual model we had in mind for all depth
infinity operations (which was not intended to normatively specify exactly
how implementations should perform the actual opertion) is that the method
is submitted to the collection resource, and then executed by the
collection.  The collection then submits the method to all its member
resources, and each of the member resources executes the method in turn.  If
one of these resources is a collection, then it would repeat the process.

In this model, we wanted all of the parameters (HTTP headers) that are
applied to each member to be the same.  However, this doesn't work for the
Destination header, since the destination header gives the top of the new
hierarchy.  As a result, the destination header needs to be changed for each
member resource to correctly state the new destination for that resource.

For example, if you have a collection, a, with members x and y, and you are
copying a with depth infinity to g, the destination headers for each
resource are:

a: Destination: g
a/x: Destination: g/x
a/y: Destination: g/y

Without the Destination rewriting, the destination header would always be g:

a: Destination: g
a/x: Destination: g
a/y: Destination: g

In this case, each copy would overwrite the previous resource. Avoiding this
situation is the reason we added para 5, "The Destination header only
specifies the destination URI for the Request-URI..."

Note that your implementation does not need to actually use this model for
recursing the method invocations from resource to resource.  If you have a
repository that has a deep copy operation already within it, you will
probably be able to implement a depth COPY using this function.

> The RFC section 8.8.3 3rd para states that the collection and its
> properties are copied, but no resources. We tested COPY with a
> Depth 0 using source of /a to destination /d on two implementations.
> Both implementations tested did not appear to copy the source collection.
> Our interpretation is that the source collection /a should have been
> copied to the destination i.e. resulting in /a/d.

Hmm, well, after the copy, there should have been two collections, /a, and
its copy, /d.  You would only have a collection /a/d if the destination was
a/d.

Does this affect the results of your test?  It is also possible that these
implementations aren't compliant with the spec. (perhaps the spec. itself
needs to be changed).

- Jim