Note, however, that as new methods are created it will be necessary
   to specify how they interact with a write lock.

7.2 Write Locks and Lock Tokens

   A successful request for an exclusive or shared write lock MUST
   result in the generation of a unique lock token associated with the
   requesting principal.  Thus if five principals have a shared write
   lock on the same resource there will be five lock tokens, one for
   each principal.

7.3 Write Locks and Properties

   While those without a write lock may not alter a property on a
   resource it is still possible for the values of live properties to
   change, even while locked, due to the requirements of their schemas.





 
RFC 2518                         WEBDAV                    February 1999


   Only dead properties and live properties defined to respect locks are
   guaranteed not to change while write locked.

7.4 Write Locks and Null Resources

   It is possible to assert a write lock on a null resource in order to
   lock the name.

   A write locked null resource, referred to as a lock-null resource,
   MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to
   any HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND,
   LOCK, and UNLOCK.  A lock-null resource MUST appear as a member of
   its parent collection.  Additionally the lock-null resource MUST have
   defined on it all mandatory DAV properties.  Most of these
   properties, such as all the get* properties, will have no value as a
   lock-null resource does not support the GET method.  Lock-Null
   resources MUST have defined values for lockdiscovery and
   supportedlock properties.

   Until a method such as PUT or MKCOL is successfully executed on the
   lock-null resource the resource MUST stay in the lock-null state.
   However, once a PUT or MKCOL is successfully executed on a lock-null
   resource the resource ceases to be in the lock-null state.

   If the resource is unlocked, for any reason, without a PUT, MKCOL, or
   similar method having been successfully executed upon it then the
   resource MUST return to the null state.

7.5 Write Locks and Collections

   A write lock on a collection, whether created by a "Depth: 0" or
   "Depth: infinity" lock request, prevents the addition or removal of
   member URIs of the collection by non-lock owners.  As a consequence,
   when a principal issues a PUT or POST request to create a new
   resource under a URI which needs to be an internal member of a write
   locked collection to maintain HTTP namespace consistency, or issues a
   DELETE to remove a resource which has a URI which is an existing
   internal member URI of a write locked collection, this request MUST
   fail if the principal does not have a write lock on the collection.

   However, if a write lock request is issued to a collection containing
   member URIs identifying resources that are currently locked in a
   manner which conflicts with the write lock, the request MUST fail
   with a 423 (Locked) status code.

   If a lock owner causes the URI of a resource to be added as an
   internal member URI of a locked collection then the new resource MUST
   be automatically added to the lock.  This is the only mechanism that




 
RFC 2518                         WEBDAV                    February 1999


   allows a resource to be added to a write lock.  Thus, for example, if
   the collection /a/b/ is write locked and the resource /c is moved to
   /a/b/c then resource /a/b/c will be added to the write lock.

7.6 Write Locks and the If Request Header

   If a user agent is not required to have knowledge about a lock when
   requesting an operation on a locked resource, the following scenario
   might occur.  Program A, run by User A, takes out a write lock on a
   resource.  Program B, also run by User A, has no knowledge of the
   lock taken out by Program A, yet performs a PUT to the locked
   resource.  In this scenario, the PUT succeeds because locks are
   associated with a principal, not a program, and thus program B,
   because it is acting with principal A's credential, is allowed to
   perform the PUT.  However, had program B known about the lock, it
   would not have overwritten the resource, preferring instead to
   present a dialog box describing the conflict to the user.  Due to
   this scenario, a mechanism is needed to prevent different programs
   from accidentally ignoring locks taken out by other programs with the