WebDAV BIND question: specifics of COPY behavior

[Julian Reschke <[e-mail]>]

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