WebDAV BIND question: specifics of COPY behavior

[Julian Reschke]

Hi,

the following question reached me off-list:

 > - Section 2.3.2: I'm not sure if allowing undefined behaviour in this
 > case is a good or bad idea. It seems like it might surprise a
 > potential user.

So this refers to the (new, as of version -24) example in 2.3.2, and to
the spec text in
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-24.html#rfc.section.2.3.p.4>:

"If a COPY request causes an existing resource to be updated, the
bindings to that resource MUST be unaffected by the COPY request. Using
the preceding example, suppose that a COPY request is issued to URI-X
for resource R', with the Destination header set to URI-2. The content
and dead properties of resource R would be updated to be a copy of those
of resource R', but the mappings from URI-1, URI-2, and URI-3 to
resource R remain unaffected. If because of multiple bindings to a
resource, more than one source resource updates a single destination
resource, the order of the updates is server defined (see Section 2.3.2
for an example)."

Answer: it is very hard to specify the behavior for COPY when
overwriting existing resources, even in absence of multiple bindings.

RFC 2518 started with a very simplistic view:

"If a resource exists at the destination and the Overwrite header is "T"
then prior to performing the copy the server MUST perform a DELETE with
"Depth: infinity" on the destination resource. If the Overwrite header
is set to "F" then the operation will fail." --
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.8.4>

That proved to be too simple, because it means that copying *to* a
version-controlled resource always wipes out the versioning meta data.
Thus RFC 3253 changed it to:

"RFC 2518, Section 8.8.4 states:

"If a resource exists at the destination and the Overwrite header is "T"
then prior to performing the copy the server MUST perform a DELETE with
"Depth: infinity" on the destination resource."

The purpose of this sentence is to ensure that following a COPY, all
destination resources have the same content and dead properties as the
corresponding resources identified by the request-URL (where a resource
with a given name relative to the Destination URL "corresponds" to a
resource with the same name relative to the request-URL). If at the time
of the request, there already is a resource at the destination that has
the same resource type as the corresponding resource at the request-URL,
that resource MUST NOT be deleted, but MUST be updated to have the
content and dead properties of its corresponding member. If a client
wishes all resources at the destination to be deleted prior to the COPY,
it MUST explicitly issue a DELETE request.

The difference between updating a resource and replacing a resource with
a new resource is especially important when resource history is being
maintained (the former adds to an existing history, while the latter
creates a new history). In addition, locking and access control
constraints might allow you to update a resource, but not allow you to
delete it and create a new one in its place.

Note that this clarification does not apply to a MOVE request. A MOVE
request with Overwrite:T MUST perform the DELETE with "Depth:infinity"
on the destination resource prior to performing the MOVE." --
<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.1.7>

This is also reflected in the revision of RFC 2518, RFC 4918:

"If a COPY request has an Overwrite header with a value of "F", and a
resource exists at the Destination URL, the server MUST fail the request.

When a server executes a COPY request and overwrites a destination
resource, the exact behavior MAY depend on many factors, including
WebDAV extension capabilities (see particularly [RFC3253]). For example,
when an ordinary resource is overwritten, the server could delete the
target resource before doing the copy, or could do an in-place overwrite
to preserve live properties.

When a collection is overwritten, the membership of the destination
collection after the successful COPY request MUST be the same membership
as the source collection immediately before the COPY. Thus, merging the
membership of the source and destination collections together in the
destination is not a compliant behavior.

In general, if clients require the state of the destination URL to be
wiped out prior to a COPY (e.g., to force live properties to be reset),
then the client could send a DELETE to the destination before the COPY
request to ensure this reset." --
<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.9.8.4>

In general, clients always have the choice of deleting the target
resource explicitly. In that case, the BIND spec already says the server
SHOULD preserve the binding structure:

"If a COPY request would cause a new resource to be created as a copy of
an existing resource, and that COPY request has already created a copy
of that existing resource, the COPY request instead creates another
binding to the previous copy, instead of creating a new resource (see
Section 2.3.3 for an example)." --
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-24.html#rfc.section.2.3.p.5>

For the case discussed in 2.3.2, it just didn't seem sensible to require
a specific choice; whatever we could have chosen might have been hard to
implement on specific backends (where the copy process get's delegated
to a storage system that is independent of WebDAV).

BR, Julian