RFC 2518                         WEBDAV                    February 1999


8.5 POST for Collections

   Since by definition the actual function performed by POST is
   determined by the server and often depends on the particular
   resource, the behavior of POST when applied to collections cannot be
   meaningfully modified because it is largely undefined.  Thus the
   semantics of POST are unmodified when applied to a collection.

8.6 DELETE

   8.6.1 DELETE for Non-Collection Resources

   If the DELETE method is issued to a non-collection resource whose
   URIs are an internal member of one or more collections, then during
   DELETE processing a server MUST remove any URI for the resource
   identified by the Request-URI from collections which contain it as a
   member.

8.6.2 DELETE for Collections

   The DELETE method on a collection MUST act as if a "Depth: infinity"
   header was used on it.  A client MUST NOT submit a Depth header with
   a DELETE on a collection with any value but infinity.

   DELETE instructs that the collection specified in the Request-URI and
   all resources identified by its internal member URIs are to be
   deleted.

   If any resource identified by a member URI cannot be deleted then all
   of the member's ancestors MUST NOT be deleted, so as to maintain
   namespace consistency.

   Any headers included with DELETE MUST be applied in processing every
   resource to be deleted.

   When the DELETE method has completed processing it MUST result in a
   consistent namespace.

   If an error occurs with a resource other than the resource identified
   in the Request-URI then the response MUST be a 207 (Multi-Status).
   424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-
   Status).  They can be safely left out because the client will know
   that the ancestors of a resource could not be deleted when the client
   receives an error for the ancestor's progeny.  Additionally 204 (No
   Content) errors SHOULD NOT be returned in the 207 (Multi-Status).
   The reason for this prohibition is that 204 (No Content) is the
   default success code.





 
RFC 2518                         WEBDAV                    February 1999


8.6.2.1 Example - DELETE

   >>Request

   DELETE  /container/ HTTP/1.1
   Host: www.foo.bar

   >>Response

   HTTP/1.1 207 Multi-Status
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <d:multistatus xmlns:d="DAV:">
     
          http://www.foo.bar/container/resource3
          HTTP/1.1 423 Locked
     </d:response>
   </d:multistatus>

   In this example the attempt to delete
   http://www.foo.bar/container/resource3 failed because it is locked,
   and no lock token was submitted with the request. Consequently, the
   attempt to delete http://www.foo.bar/container/ also failed. Thus the
   client knows that the attempt to delete http://www.foo.bar/container/
   must have also failed since the parent can not be deleted unless its
   child has also been deleted.  Even though a Depth header has not been
   included, a depth of infinity is assumed because the method is on a
   collection.

8.7 PUT

8.7.1 PUT for Non-Collection Resources