the outputs from a set uniformly distributed inputs are themselves
   uniformly distributed, and that a single bit change in the input can
   be expected to cause half of the output bits to change.






 
RFC 2518                         WEBDAV                    February 1999


6.5 Lock Capability Discovery

   Since server lock support is optional, a client trying to lock a
   resource on a server can either try the lock and hope for the best,
   or perform some form of discovery to determine what lock capabilities
   the server supports.  This is known as lock capability discovery.
   Lock capability discovery differs from discovery of supported access
   control types, since there may be access control types without
   corresponding lock types.  A client can determine what lock types the
   server supports by retrieving the supportedlock property.

   Any DAV compliant resource that supports the LOCK method MUST support
   the supportedlock property.

6.6 Active Lock Discovery

   If another principal locks a resource that a principal wishes to
   access, it is useful for the second principal to be able to find out
   who the first principal is.  For this purpose the lockdiscovery
   property is provided.  This property lists all outstanding locks,
   describes their type, and where available, provides their lock token.

   Any DAV compliant resource that supports the LOCK method MUST support
   the lockdiscovery property.

6.7 Usage Considerations

   Although the locking mechanisms specified here provide some help in
   preventing lost updates, they cannot guarantee that updates will
   never be lost.  Consider the following scenario:

   Two clients A and B are interested in editing the resource
   'index.html'.  Client A is an HTTP client rather than a WebDAV
   client, and so does not know how to perform locking.
   Client A doesn't lock the document, but does a GET and begins
   editing.
   Client B does LOCK, performs a GET and begins editing.
   Client B finishes editing, performs a PUT, then an UNLOCK.
   Client A performs a PUT, overwriting and losing all of B's changes.

   There are several reasons why the WebDAV protocol itself cannot
   prevent this situation.  First, it cannot force all clients to use
   locking because it must be compatible with HTTP clients that do not
   comprehend locking.  Second, it cannot require servers to support
   locking because of the variety of repository implementations, some of
   which rely on reservations and merging rather than on locking.
   Finally, being stateless, it cannot enforce a sequence of operations
   like LOCK / GET / PUT / UNLOCK.




 
RFC 2518                         WEBDAV                    February 1999


   WebDAV servers that support locking can reduce the likelihood that
   clients will accidentally overwrite each other's changes by requiring
   clients to lock resources before modifying them.  Such servers would
   effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying
   resources.

   WebDAV clients can be good citizens by using a lock / retrieve /
   write /unlock sequence of operations (at least by default) whenever
   they interact with a WebDAV server that supports locking.

   HTTP 1.1 clients can be good citizens, avoiding overwriting other
   clients' changes, by using entity tags in If-Match headers with any
   requests that would modify resources.

   Information managers may attempt to prevent overwrites by
   implementing client-side procedures requiring locking before
   modifying WebDAV resources.

7  Write Lock

   This section describes the semantics specific to the write lock type.
   The write lock is a specific instance of a lock type, and is the only
   lock type described in this specification.

7.1 Methods Restricted by Write Locks

   A write lock MUST prevent a principal without the lock from
   successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE,
   DELETE, or MKCOL on the locked resource.  All other current methods,
   GET in particular, function independently of the lock.