W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2006

[Bug 106] COPY and the Overwrite Header vs merge behaviour desc added

From: <bugzilla@soe.ucsc.edu>
Date: Sat, 7 Jan 2006 14:05:08 -0800
Message-Id: <200601072205.k07M58AY029347@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org


julian.reschke@greenbytes.de changed:

           What    |Removed                     |Added
            Version|-08                         |-10

------- Additional Comments From julian.reschke@greenbytes.de  2006-01-07 14:05 -------
The new text in

"8.9.4 COPY and Overwriting Destination Resources

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

I think this is good. I would replace the "MAY" in the 1st sentence of the 2dn
paragraph by "may", though.

------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Saturday, 7 January 2006 22:05:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:35 UTC