W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

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

From: <bugzilla@soe.ucsc.edu>
Date: Sat, 10 Dec 2005 09:53:34 -0800
Message-Id: <200512101753.jBAHrY00009288@ietf.cse.ucsc.edu>
To: w3c-dist-auth@w3.org

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=106

julian.reschke@greenbytes.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|julian.reschke@greenbytes.de|ejw@cs.ucsc.edu
             Status|ASSIGNED                    |NEW



------- Additional Comments From julian.reschke@greenbytes.de  2005-12-10 09:53 -------
I agree that the new text isn't perfect. Quoting:

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]).  Some
   considerations:

..."MAY" is incorrect here, because we aren't defining anything here... Also, if
we refer to RFC3253, we'd better also state the exact place (here: Section 1.7).

      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.

That's correct.

      When a collection is overwritten, the source collection membership
      could completely replace the destination collection membership, or
      the source collection membership could be combined with the
      destination collection membership.

I don't think this is allowed. The membership should be always the one of the
source namespace, unless I'm missing something.

   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
   or to force collection membership to be reset), then the client could
   send a DELETE to the destination before the COPY request to ensure
   this reset.

That's correct, but only for the first of the two reasons.




------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
Received on Saturday, 10 December 2005 17:53:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:11 GMT