Web Distributed Authoring and Versioning (WebDAV) Locking Protocol

This document specifies a set of methods and headers ancillary to HTTP/1.1 (RFC2616) and Distributed Authoring and Versioning (WebDAV, RFC2518) for the management of resource locking (collision avoidance). It updates those sections from RFC2518 that specify WebDAV's locking features.¶

[rfc.comment.1: Note that this document is not a product of the WebDAV working group. It is just an experiment to study the feasability of extracing the locking feature into a separate specification. --reschke] [rfc.comment.2: This version of this document doesn't yet contain any new or rewritten text - it only contains text copied verbatim fro RFC2518 and GULP. It's sole purpose is be a reference point for all future changes. --reschke] ¶

Distribution of this document is unlimited. Please send comments to the WebDAV working group at w3c-dist-auth@w3.org, which may be joined by sending a message with subject "subscribe" to w3c-dist-auth-request@w3.org.¶

Appendix A. Text to be integrated from RFC2518

A.1. Introduction

Locking: The ability to keep more than one person from working on a document at the same time. This prevents the "lost update problem," in which modifications are lost as first one author then another writes changes without merging the other author's changes.¶

A.2. Locking

The ability to lock a resource provides a mechanism for serializing access to that resource. Using a lock, an authoring client can provide a reasonable guarantee that another principal will not modify a resource while it is being edited. In this way, a client can prevent the "lost update" problem.¶

This specification allows locks to vary over two client-specified parameters, the number of principals involved (exclusive vs. shared) and the type of access to be granted. This document defines locking for only one access type, write. However, the syntax is extensible, and permits the eventual specification of locking for other access types.¶

A.2.1. Exclusive Vs. Shared Locks

The most basic form of lock is an exclusive lock. This is a lock where the access right in question is only granted to a single principal. The need for this arbitration results from a desire to avoid having to merge results.¶

However, there are times when the goal of a lock is not to exclude others from exercising an access right but rather to provide a mechanism for principals to indicate that they intend to exercise their access rights. Shared locks are provided for this case. A shared lock allows multiple principals to receive a lock. Hence any principal with appropriate access can get the lock.¶

With shared locks there are two trust sets that affect a resource. The first trust set is created by access permissions. Principals who are trusted, for example, may have permission to write to the resource. Among those who have access permission to write to the resource, the set of principals who have taken out a shared lock also must trust each other, creating a (typically) smaller trust set within the access permission write set.¶

Starting with every possible principal on the Internet, in most situations the vast majority of these principals will not have write access to a given resource. Of the small number who do have write access, some principals may decide to guarantee their edits are free from overwrite conflicts by using exclusive write locks. Others may decide they trust their collaborators will not overwrite their work (the potential set of collaborators being the set of principals who have write permission) and use a shared lock, which informs their collaborators that a principal may be working on the resource.¶

The WebDAV extensions to HTTP do not need to provide all of the communications paths necessary for principals to coordinate their activities. When using shared locks, principals may use any out of band communication channel to coordinate their work (e.g., face-to-face interaction, written notes, post-it notes on the screen, telephone conversation, Email, etc.) The intent of a shared lock is to let collaborators know who else may be working on a resource.¶

Shared locks are included because experience from web distributed authoring systems has indicated that exclusive locks are often too rigid. An exclusive lock is used to enforce a particular editing process: take out an exclusive lock, read the resource, perform edits, write the resource, release the lock. This editing process has the problem that locks are not always properly released, for example when a program crashes, or when a lock owner leaves without unlocking a resource. While both timeouts and administrative action can be used to remove an offending lock, neither mechanism may be available when needed; the timeout may be long or the administrator may not be available.¶

A.2.2. Required Support

A WebDAV compliant server is not required to support locking in any form. If the server does support locking it may choose to support any combination of exclusive and shared locks for any access types.¶

The reason for this flexibility is that locking policy strikes to the very heart of the resource management and versioning systems employed by various storage repositories. These repositories require control over what sort of locking will be made available. For example, some repositories only support shared write locks while others only provide support for exclusive write locks while yet others use no locking at all. As each system is sufficiently different to merit exclusion of certain locking features, this specification leaves locking as the sole axis of negotiation within WebDAV.¶

A.2.3. Lock Tokens

A lock token is a type of state token, represented as a URI, which identifies a particular lock. A lock token is returned by every successful LOCK operation in the lockdiscovery property in the response body, and can also be found through lock discovery on a resource.¶

Lock token URIs MUST be unique across all resources for all time. This uniqueness constraint allows lock tokens to be submitted across resources and servers without fear of confusion.¶

This specification provides a lock token URI scheme called opaquelocktoken that meets the uniqueness requirements. However resources are free to return any URI scheme so long as it meets the uniqueness requirements.¶

Having a lock token provides no special access rights. Anyone can find out anyone else's lock token by performing lock discovery. Locks MUST be enforced based upon whatever authentication mechanism is used by the server, not based on the secrecy of the token values.¶

A.2.4. opaquelocktoken Lock Token URI Scheme

The opaquelocktoken URI scheme is designed to be unique across all resources for all time. Due to this uniqueness quality, a client may submit an opaque lock token in an If header on a resource other than the one that returned it.¶

All resources MUST recognize the opaquelocktoken scheme and, at minimum, recognize that the lock token does not refer to an outstanding lock on the resource.¶

In order to guarantee uniqueness across all resources for all time the opaquelocktoken requires the use of the Universal Unique Identifier (UUID) mechanism, as described in [ISO-11578].¶

Opaquelocktoken generators, however, have a choice of how they create these tokens. They can either generate a new UUID for every lock token they create or they can create a single UUID and then add extension characters. If the second method is selected then the program generating the extensions MUST guarantee that the same extension will never be used twice with the associated UUID.¶

OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension] ; The UUID production is the string representation of a UUID, as defined in [ISO-11578]. Note that white space (LWS) is not allowed between elements of this production.¶

Extension = path ; path is defined in section 3.2.1 of RFC 2068 [RFC2068] ¶

A.2.4.1. Node Field Generation Without the IEEE 802 Address

UUIDs, as defined in [ISO-11578], contain a "node" field that contains one of the IEEE 802 addresses for the server machine. As noted in Appendix A.10.2, there are several security risks associated with exposing a machine's IEEE 802 address. This section provides an alternate mechanism for generating the "node" field of a UUID which does not employ an IEEE 802 address. WebDAV servers MAY use this algorithm for creating the node field when generating UUIDs. The text in this section is originally from an Internet-Draft by Paul Leach and Rich Salz, who are noted here to properly attribute their work.¶

The ideal solution is to obtain a 47 bit cryptographic quality random number, and use it as the low 47 bits of the node ID, with the most significant bit of the first octet of the node ID set to 1. This bit is the unicast/multicast bit, which will never be set in IEEE 802 addresses obtained from network cards; hence, there can never be a conflict between UUIDs generated by machines with and without network cards.¶

If a system does not have a primitive to generate cryptographic quality random numbers, then in most systems there are usually a fairly large number of sources of randomness available from which one can be generated. Such sources are system specific, but often include:¶

the percent of memory in use
the size of main memory in bytes
the amount of free main memory in bytes
the size of the paging or swap file in bytes
free bytes of paging or swap file
the total size of user virtual address space in bytes
the total available user address space bytes
the size of boot disk drive in bytes
the free disk space on boot drive in bytes
the current time
the amount of time since the system booted
the individual sizes of files in various system directories
the creation, last read, and modification times of files in various system directories
the utilization factors of various system resources (heap, etc.)
current mouse cursor position
current caret position
current number of running processes, threads
handles or IDs of the desktop window and the active window
the value of stack pointer of the caller
the process and thread ID of caller
various processor architecture specific performance counters (instructions executed, cache misses, TLB misses)

(Note that it is precisely the above kinds of sources of randomness that are used to seed cryptographic quality random number generators on systems without special hardware for their construction.)¶

In addition, items such as the computer's name and the name of the operating system, while not strictly speaking random, will help differentiate the results from those obtained by other systems.¶

The exact algorithm to generate a node ID using these data is system specific, because both the data available and the functions to obtain them are often very system specific. However, assuming that one can concatenate all the values from the randomness sources into a buffer, and that a cryptographic hash function such as MD5 is available, then any 6 bytes of the MD5 hash of the buffer, with the multicast bit (the high bit of the first byte) set will be an appropriately random node ID.¶

Other hash functions, such as SHA-1, can also be used. The only requirement is that the result be suitably random _ in the sense that 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.¶

A.2.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.¶

A.2.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.¶

A.2.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.¶

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.¶

A.3. 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.¶

A.3.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.¶

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

A.3.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.¶

A.3.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. Only dead properties and live properties defined to respect locks are guaranteed not to change while write locked.¶

A.3.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.¶

A.3.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 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.¶

A.3.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 same authorization.¶

In order to prevent these collisions a lock token MUST be submitted by an authorized principal in the If header for all locked resources that a method may interact with or the method MUST fail. For example, if a resource is to be moved and both the source and destination are locked then two lock tokens must be submitted, one for the source and the other for the destination.¶

A.3.6.1. Example - Write Lock

>>Request

   COPY /~fielding/index.html HTTP/1.1
   Host: www.ics.uci.edu
   Destination: http://www.ics.uci.edu/users/f/fielding/index.html
   If: <http://www.ics.uci.edu/users/f/fielding/index.html>
       (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)

>>Response

   HTTP/1.1 204 No Content

In this example, even though both the source and destination are locked, only one lock token must be submitted, for the lock on the destination. This is because the source resource is not modified by a COPY, and hence unaffected by the write lock. In this example, user agent authentication has previously occurred via a mechanism outside the scope of the HTTP protocol, in the underlying transport layer.¶

A.3.7. Write Locks and COPY/MOVE

A COPY method invocation MUST NOT duplicate any write locks active on the source. However, as previously noted, if the COPY copies the resource into a collection that is locked with "Depth: infinity", then the resource will be added to the lock.¶

A successful MOVE request on a write locked resource MUST NOT move the write lock with the resource. However, the resource is subject to being added to an existing lock at the destination, as specified in Appendix A.3.5. For example, if the MOVE makes the resource a child of a collection that is locked with "Depth: infinity", then the resource will be added to that collection's lock. Additionally, if a resource locked with "Depth: infinity" is moved to a destination that is within the scope of the same lock (e.g., within the namespace tree covered by the lock), the moved resource will again be a added to the lock. In both these examples, as specified in Appendix A.3.6, an If header must be submitted containing a lock token for both the source and destination.¶

A.3.8. Refreshing Write Locks

A client MUST NOT submit the same write lock request twice. Note that a client is always aware it is resubmitting the same lock request because it must include the lock token in the If header in order to make the request for a resource that is already locked.¶

However, a client may submit a LOCK method with an If header but without a body. This form of LOCK MUST only be used to "refresh" a lock. Meaning, at minimum, that any timers associated with the lock MUST be re-set.¶

A server may return a Timeout header with a lock refresh that is different than the Timeout header returned when the lock was originally requested. Additionally clients may submit Timeout headers of arbitrary value with their lock refresh requests. Servers, as always, may ignore Timeout headers submitted by the client.¶

If an error is received in response to a refresh LOCK request the client SHOULD assume that the lock was not refreshed.¶

A.4. HTTP Headers for Distributed Authoring

A.4.1. 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.¶

A.4.1.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.¶

A.4.1.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.¶

A.4.1.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.¶

A.4.1.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.¶

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.¶

A.4.1.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 a resource MUST cause all of its locks to be removed.¶

A.4.1.6. Lock Compatibility Table

The table below describes the behavior that occurs when a lock request is made on a resource.

Current lock state / Lock request	Shared Lock	Exclusive Lock
None	True	True
Shared Lock	True	False
Exclusive Lock	False	False*

Legend: True = lock may be granted. False = lock MUST NOT be granted. *=It is illegal for a principal to request the same lock twice.

The current lock state of a resource is given in the leftmost column, and lock requests are listed in the first row. The intersection of a row and column gives the result of a lock request. For example, if a shared lock is held on a resource, and an exclusive lock is requested, the table entry is "false", indicating the lock must not be granted.¶

A.4.1.7. Status Codes

200 (OK) - The lock request succeeded and the value of the lockdiscovery property is included in the body.¶

412 (Precondition Failed) - The included lock token was not enforceable on this resource or the server could not satisfy the request in the lockinfo XML element.¶

423 (Locked) - The resource is locked, so the method has been rejected.¶

A.4.1.8. Example - Simple Lock Request

>>Request

   LOCK /workspace/webdav/proposal.doc HTTP/1.1
   Host: webdav.sb.aol.com
   Timeout: Infinite, Second-4100000000
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx
   Authorization: Digest username="ejw",
      realm="ejw@webdav.sb.aol.com", nonce="...",
      uri="/workspace/webdav/proposal.doc",
      response="...", opaque="..."

   <?xml version="1.0" encoding="utf-8" ?>
   <D:lockinfo xmlns:D='DAV:'>
     <D:lockscope><D:exclusive/></D:lockscope>
     <D:locktype><D:write/></D:locktype>
     <D:owner>
          <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
     </D:owner>
   </D:lockinfo>

>>Response

   HTTP/1.1 200 OK
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:prop xmlns:D="DAV:">
     <D:lockdiscovery>
          <D:activelock>
               <D:locktype><D:write/></D:locktype>
               <D:lockscope><D:exclusive/></D:lockscope>
               <D:depth>Infinity</D:depth>
               <D:owner>
                    <D:href>
                         http://www.ics.uci.edu/~ejw/contact.html
                    </D:href>
               </D:owner>
               <D:timeout>Second-604800</D:timeout>
               <D:locktoken>
                    <D:href>
               opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
                    </D:href>
               </D:locktoken>
          </D:activelock>
     </D:lockdiscovery>
   </D:prop>

This example shows the successful creation of an exclusive write lock on resource http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The resource http://www.ics.uci.edu/~ejw/contact.html contains contact information for the owner of the lock. The server has an activity-based timeout policy in place on this resource, which causes the lock to automatically be removed after 1 week (604800 seconds). Note that the nonce, response, and opaque fields have not been calculated in the Authorization request header.¶

A.4.1.9. Example - Refreshing a Write Lock

>>Request

   LOCK /workspace/webdav/proposal.doc HTTP/1.1
   Host: webdav.sb.aol.com
   Timeout: Infinite, Second-4100000000
   If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
   Authorization: Digest username="ejw",
      realm="ejw@webdav.sb.aol.com", nonce="...",
      uri="/workspace/webdav/proposal.doc",
      response="...", opaque="..."

>>Response

   HTTP/1.1 200 OK
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx

   <?xml version="1.0" encoding="utf-8" ?>
   <D:prop xmlns:D="DAV:">
     <D:lockdiscovery>
          <D:activelock>
               <D:locktype><D:write/></D:locktype>
               <D:lockscope><D:exclusive/></D:lockscope>
               <D:depth>Infinity</D:depth>
               <D:owner>
                    <D:href>
                    http://www.ics.uci.edu/~ejw/contact.html
                    </D:href>
               </D:owner>
               <D:timeout>Second-604800</D:timeout>
               <D:locktoken>
                    <D:href>
               opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
                    </D:href>
               </D:locktoken>
          </D:activelock>
     </D:lockdiscovery>
   </D:prop>

This request would refresh the lock, resetting any time outs. Notice that the client asked for an infinite time out but the server choose to ignore the request. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.¶

A.4.1.10. Example - Multi-Resource Lock Request

>>Request

   LOCK /webdav/ HTTP/1.1
   Host: webdav.sb.aol.com
   Timeout: Infinite, Second-4100000000
   Depth: infinity
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx
   Authorization: Digest username="ejw",
      realm="ejw@webdav.sb.aol.com", nonce="...",
      uri="/workspace/webdav/proposal.doc",
      response="...", opaque="..."

   <?xml version="1.0" encoding="utf-8" ?>
   <D:lockinfo xmlns:D="DAV:">
     <D:locktype><D:write/></D:locktype>
     <D:lockscope><D:exclusive/></D:lockscope>
     <D:owner>
          <D:href>http://www.ics.uci.edu/~ejw/contact.html</D:href>
     </D:owner>
   </D:lockinfo>

>>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:">
     <D:response>
          <D:href>http://webdav.sb.aol.com/webdav/secret</D:href>
          <D:status>HTTP/1.1 403 Forbidden</D:status>
     </D:response>
     <D:response>
          <D:href>http://webdav.sb.aol.com/webdav/</D:href>
          <D:propstat>
               <D:prop><D:lockdiscovery/></D:prop>
               <D:status>HTTP/1.1 424 Failed Dependency</D:status>
          </D:propstat>
     </D:response>
   </D:multistatus>

This example shows a request for an exclusive write lock on a collection and all its children. In this request, the client has specified that it desires an infinite length lock, if available, otherwise a timeout of 4.1 billion seconds, if available. The request entity body contains the contact information for the principal taking out the lock, in this case a web page URL.¶

The error is a 403 (Forbidden) response on the resource http://webdav.sb.aol.com/webdav/secret. Because this resource could not be locked, none of the resources were locked. Note also that the lockdiscovery property for the Request-URI has been included as required. In this example the lockdiscovery property is empty which means that there are no outstanding locks on the resource.¶

In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.¶

A.4.2. UNLOCK Method

The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header from the Request-URI, and all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail.¶

Any DAV compliant resource which supports the LOCK method MUST support the UNLOCK method.¶

A.4.2.1. Example - UNLOCK

>>Request

   UNLOCK /workspace/webdav/info.doc HTTP/1.1
   Host: webdav.sb.aol.com
   Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7>
   Authorization: Digest username="ejw",
      realm="ejw@webdav.sb.aol.com", nonce="...",
      uri="/workspace/webdav/proposal.doc",
      response="...", opaque="..."

>>Response

   HTTP/1.1 204 No Content

In this example, the lock identified by the lock token "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed from the resource http://webdav.sb.aol.com/workspace/webdav/info.doc. If this lock included more than just one resource, the lock is removed from all resources included in the lock. The 204 (No Content) status code is used instead of 200 (OK) because there is no response entity body.¶

In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header.¶

A.5. HTTP Headers for Distributed Authoring

A.5.1. DAV Header

[rfc.comment.3: Add description of compliance class "2". --reschke] ¶

A.5.2. Depth Header

[rfc.comment.4: Add "Depth" header considerations: --reschke] ¶

If a resource, source or destination, within the scope of the method with a Depth header is locked in such a way as to prevent the successful execution of the method, then the lock token for that resource MUST be submitted with the request in the If request header.¶

A.5.3. If Header

[rfc.comment.5: Add "If" header considerations: --reschke] ¶

A.5.4. Lock-Token Header

   Lock-Token = "Lock-Token" ":" Coded-URL

The Lock-Token request header is used with the UNLOCK method to identify the lock to be removed. The lock token in the Lock-Token request header MUST identify a lock that contains the resource identified by Request-URI as a member.¶

The Lock-Token response header is used with the LOCK method to indicate the lock token created as a result of a successful LOCK request to create a new lock.¶

A.5.5. Timeout Request Header

   TimeOut = "Timeout" ":" 1#TimeType
   TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
   DAVTimeOutVal = 1*digit
   Other = "Extend" field-value   ; See section 4.2 of [RFC2068]

Clients may include Timeout headers in their LOCK requests. However, the server is not required to honor or even consider these requests. Clients MUST NOT submit a Timeout request header with any method other than a LOCK method.¶

A Timeout request header MUST contain at least one TimeType and may contain multiple TimeType entries. The purpose of listing multiple TimeType entries is to indicate multiple different values and value types that are acceptable to the client. The client lists the TimeType entries in order of preference.¶

Timeout response values MUST use a Second value, Infinite, or a TimeType the client has indicated familiarity with. The server may assume a client is familiar with any TimeType submitted in a Timeout header.¶

The "Second" TimeType specifies the number of seconds that will elapse between granting of the lock at the server, and the automatic removal of the lock. The timeout value for TimeType "Second" MUST NOT be greater than 2^32-1.¶

The timeout counter SHOULD be restarted any time an owner of the lock sends a method to any member of the lock, including unsupported methods, or methods which are unsuccessful. However the lock MUST be refreshed if a refresh LOCK method is successfully received.¶

If the timeout expires then the lock may be lost. Specifically, if the server wishes to harvest the lock upon time-out, the server SHOULD act as if an UNLOCK method was executed by the server on the resource using the lock token of the timed-out lock, performed with its override authority. Thus logs should be updated with the disposition of the lock, notifications should be sent, etc., just as they would be for an UNLOCK request.¶

Servers are advised to pay close attention to the values submitted by clients, as they will be indicative of the type of activity the client intends to perform. For example, an applet running in a browser may need to lock a resource, but because of the instability of the environment within which the applet is running, the applet may be turned off without warning. As a result, the applet is likely to ask for a relatively small timeout value so that if the applet dies, the lock can be quickly harvested. However, a document management system is likely to ask for an extremely long timeout because its user may be planning on going off-line.¶

A client MUST NOT assume that just because the time-out has expired the lock has been lost.¶

A.6. Status Code Extensions to HTTP/1.1

A.6.1. 423 Locked

The 423 (Locked) status code means the source or destination resource of a method is locked.¶

A.7. XML Element Definitions

A.7.1. activelock XML Element

Name:: activelock
Namespace:: DAV:
Purpose:: Describes a lock on a resource.

   <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
   locktoken?) >

A.7.1.1. depth XML Element

Name:: depth
Namespace:: DAV:
Purpose:: The value of the Depth header.
Value:: "0" | "1" | "infinity"

   <!ELEMENT depth (#PCDATA) >

A.7.1.2. locktoken XML Element

Name:: locktoken
Namespace:: DAV:
Purpose:: The lock token associated with a lock. Description: The href contains one or more opaque lock token URIs which all refer to the same lock (i.e., the OpaqueLockToken-URI production in Appendix A.2.4).

   <!ELEMENT locktoken (href+) >

A.7.1.3. timeout XML Element

Name:: timeout
Namespace:: DAV:
Purpose:: The timeout associated with a lock
Value:: TimeType ;Defined in Appendix A.5.5

   <!ELEMENT timeout (#PCDATA) >

A.7.2. lockentry XML Element

Name:: lockentry
Namespace:: DAV:
Purpose:: Defines the types of locks that can be used with the resource.

   <!ELEMENT lockentry (lockscope, locktype) >

A.7.3. lockinfo XML Element

Name:: lockinfo
Namespace:: DAV:
Purpose:: The lockinfo XML element is used with a LOCK method to specify the type of lock the client wishes to have created.

   <!ELEMENT lockinfo (lockscope, locktype, owner?) >

A.7.4. lockscope XML Element

Name:: lockscope
Namespace:: DAV:
Purpose:: Specifies whether a lock is an exclusive lock, or a shared lock.

   <!ELEMENT lockscope (exclusive | shared) >

A.7.4.1. exclusive XML Element

Name:: exclusive
Namespace:: DAV:
Purpose:: Specifies an exclusive lock

   <!ELEMENT exclusive EMPTY >

A.7.4.2. shared XML Element

Name:: shared
Namespace:: DAV:
Purpose:: Specifies a shared lock

   <!ELEMENT shared EMPTY >

A.7.5. locktype XML Element

Name:: locktype
Namespace:: DAV:
Purpose:: Specifies the access type of a lock. At present, this specification only defines one lock type, the write lock.

   <!ELEMENT locktype (write) >

A.7.5.1. write XML Element

Name:: write
Namespace:: DAV:
Purpose:: Specifies a write lock.

   <!ELEMENT write EMPTY >

A.7.6. owner XML Element

Name:: owner
Namespace:: DAV:
Purpose:: Provides information about the principal taking out a lock.
Description:: The owner XML element provides information sufficient for either directly contacting a principal (such as a telephone number or Email URI), or for discovering the principal (such as the URL of a homepage) who owns a lock.

   <!ELEMENT owner ANY>

A.8. DAV Properties

A.8.1. lockdiscovery Property

Name:: lockdiscovery
Namespace:: DAV:
Purpose:: Describes the active locks on a resource
Description:: The lockdiscovery property returns a listing of who has a lock, what type of lock he has, the timeout type and the time remaining on the timeout, and the associated lock token. The server is free to withhold any or all of this information if the requesting principal does not have sufficient access rights to see the requested data.

   <!ELEMENT lockdiscovery (activelock)* >

A.8.1.1. Example - Retrieving the lockdiscovery Property

>>Request

   PROPFIND /container/ HTTP/1.1
   Host: www.foo.bar
   Content-Length: xxxx
   Content-Type: text/xml; charset="utf-8"

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D='DAV:'>
     <D:prop><D:lockdiscovery/></D:prop>
   </D:propfind>

>>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:'>
     <D:response>
          <D:href>http://www.foo.bar/container/</D:href>
          <D:propstat>
               <D:prop>
                    <D:lockdiscovery>
                         <D:activelock>
                              <D:locktype><D:write/></D:locktype>
                              <D:lockscope><D:exclusive/></D:lockscope>
                              <D:depth>0</D:depth>
                              <D:owner>Jane Smith</D:owner>
                              <D:timeout>Infinite</D:timeout>
                              <D:locktoken>
                                   <D:href>
               opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
                                   </D:href>
                              </D:locktoken>
                         </D:activelock>
                    </D:lockdiscovery>
               </D:prop>
               <D:status>HTTP/1.1 200 OK</D:status>
          </D:propstat>
     </D:response>
   </D:multistatus>

This resource has a single exclusive write lock on it, with an infinite timeout.¶

A.8.2. supportedlock Property

Name:: supportedlock
Namespace:: DAV:
Purpose:: To provide a listing of the lock capabilities supported by the resource.
Description:: The supportedlock property of a resource returns a listing of the combinations of scope and access types which may be specified in a lock request on the resource. Note that the actual contents are themselves controlled by access controls so a server is not required to provide information the client is not authorized to see.

   <!ELEMENT supportedlock (lockentry)* >

A.8.2.1. Example - Retrieving the supportedlock Property

>>Request

   PROPFIND  /container/ HTTP/1.1
   Host: www.foo.bar
   Content-Length: xxxx
   Content-Type: text/xml; charset="utf-8"

   <?xml version="1.0" encoding="utf-8" ?>
   <D:propfind xmlns:D="DAV:">
     <D:prop><D:supportedlock/></D:prop>
   </D:propfind>

>>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:">
     <D:response>
          <D:href>http://www.foo.bar/container/</D:href>
          <D:propstat>
               <D:prop>
                    <D:supportedlock>
                         <D:lockentry>
                              <D:lockscope><D:exclusive/></D:lockscope>
                              <D:locktype><D:write/></D:locktype>
                         </D:lockentry>
                         <D:lockentry>
                              <D:lockscope><D:shared/></D:lockscope>
                              <D:locktype><D:write/></D:locktype>
                         </D:lockentry>
                    </D:supportedlock>
               </D:prop>
               <D:status>HTTP/1.1 200 OK</D:status>
          </D:propstat>
     </D:response>
   </D:multistatus>

A.9. DAV Compliance Classes

A.9.1. Class 2

A class 2 compliant resource MUST meet all class 1 requirements and support the LOCK method, the supportedlock property, the lockdiscovery property, the Time-Out response header and the Lock-Token request header. A class "2" compliant resource SHOULD also support the Time-Out request header and the owner XML element.¶

Class 2 compliant resources MUST return, at minimum, the values "1" and "2" in the DAV header on all responses to the OPTIONS method.¶

A.10. Security Considerations

A.10.1. Authentication of Clients

Furthermore, the introduction of locking functionality requires support for authentication.¶

A.10.2. Privacy Issues Connected to Locks

When submitting a lock request a user agent may also submit an owner XML field giving contact information for the person taking out the lock (for those cases where a person, rather than a robot, is taking out the lock). This contact information is stored in a lockdiscovery property on the resource, and can be used by other collaborators to begin negotiation over access to the resource. However, in many cases this contact information can be very private, and should not be widely disseminated. Servers SHOULD limit read access to the lockdiscovery property as appropriate. Furthermore, user agents SHOULD provide control over whether contact information is sent at all, and if contact information is sent, control over exactly what information is sent.¶

A.11. IANA Considerations

This specification also defines a URI scheme for the encoding of lock tokens, the opaquelocktoken URI scheme described in Appendix A.2.4.¶

13. Normative References