8.10 LOCK Method

   The following sections describe the LOCK method, which is used to
   take out a lock of any access type.  These sections on the LOCK
   method describe only those semantics that are specific to the LOCK
   method and are independent of the access type of the lock being
   requested.

   Any resource which supports the LOCK method MUST, at minimum, support
   the XML request and response formats defined herein.










 
RFC 2518                         WEBDAV                    February 1999


8.10.1 Operation

   A LOCK method invocation creates the lock specified by the lockinfo
   XML element on the Request-URI.  Lock method requests SHOULD have a
   XML request body which contains an owner XML element for this lock
   request, unless this is a refresh request. The LOCK request may have
   a Timeout header.

   Clients MUST assume that locks may arbitrarily disappear at any time,
   regardless of the value given in the Timeout header.  The Timeout
   header only indicates the behavior of the server if "extraordinary"
   circumstances do not occur.  For example, an administrator may remove
   a lock at any time or the system may crash in such a way that it
   loses the record of the lock's existence. The response MUST contain
   the value of the lockdiscovery property in a prop XML element.

   In order to indicate the lock token associated with a newly created
   lock, a Lock-Token response header MUST be included in the response
   for every successful LOCK request for a new lock.  Note that the
   Lock-Token header would not be returned in the response for a
   successful refresh LOCK request because a new lock was not created.

8.10.2 The Effect of Locks on Properties and Collections

   The scope of a lock is the entire state of the resource, including
   its body and associated properties.  As a result, a lock on a
   resource MUST also lock the resource's properties.

   For collections, a lock also affects the ability to add or remove
   members.  The nature of the effect depends upon the type of access
   control involved.

8.10.3 Locking Replicated Resources

   A resource may be made available through more than one URI. However
   locks apply to resources, not URIs. Therefore a LOCK request on a
   resource MUST NOT succeed if can not be honored by all the URIs
   through which the resource is addressable.

8.10.4 Depth and Locking

   The Depth header may be used with the LOCK method.  Values other than
   0 or infinity MUST NOT be used with the Depth header on a LOCK
   method.  All resources that support the LOCK method MUST support the
   Depth header.

   A Depth header of value 0 means to just lock the resource specified
   by the Request-URI.




 
RFC 2518                         WEBDAV                    February 1999


   If the Depth header is set to infinity then the resource specified in
   the Request-URI along with all its internal members, all the way down
   the hierarchy, are to be locked.  A successful result MUST return a
   single lock token which represents all the resources that have been
   locked.  If an UNLOCK is successfully executed on this token, all
   associated resources are unlocked.  If the lock cannot be granted to
   all resources, a 409 (Conflict) status code MUST be returned with a
   response entity body containing a multistatus XML element describing
   which resource(s) prevented the lock from being granted.  Hence,
   partial success is not an option.  Either the entire hierarchy is
   locked or no resources are locked.

   If no Depth header is submitted on a LOCK request then the request
   MUST act as if a "Depth:infinity" had been submitted.

8.10.5 Interaction with other Methods

   The interaction of a LOCK with various methods is dependent upon the
   lock type.  However, independent of lock type, a successful DELETE of