RE: WebDAV COPY/MOVE Question

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.
>
> 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.

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:
>
> 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).

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.

> 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.

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

Received on Wednesday, 19 April 2000 13:13:09 UTC