6. 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 locks) 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.

6.1 Lock Model

This section provides a non-normative description of WebDAV locking.

A lock is identified by a lock token. Lock tokens are URLs and can be transmitted over HTTP. A lock token is associated with only one lock.

Locks can be exclusive or shared. The type of lock determines how the server handles requests on the locked resource:

Exclusive Lock:

• Only the principal who created the lock can modify the resource
• Prevents any other principal from obtaining a conflicting lock

Shared Lock:

• Multiple principals can hold shared locks
• All principals holding shared locks can modify the resource
• Prevents principals not holding locks from modifying the resource

Locks can have different scopes:

• Direct Lock: The lock applies directly to the resource
• Depth Lock: The lock applies to the resource and all its members

For collections, depth can be specified:

• Depth: 0: Locks only the collection itself
• Depth: infinity: Locks the collection and all its members (recursively)

6.2 Exclusive vs. Shared Locks

The most common type of lock is an exclusive lock. The purpose of an exclusive lock is to enforce a particular principal's editing policy. A common use of an exclusive lock is to prevent different principals from modifying a resource during a long authoring session.

Shared locks are designed to support collaborative authoring, where a group of principals needs to modify a resource simultaneously. The key characteristic of shared locks is that multiple principals can hold shared locks, but exclusive locks exclude all other locks.

Lock Compatibility Table:

Current State	Shared Lock Request	Exclusive Lock Request
None	✅ True	✅ True
Shared Lock	✅ True	❌ False
Exclusive Lock	❌ False	❌ False

6.3 Required Support

A server MUST support exclusive write locks.

A server MAY support shared write locks. If a server does not support shared write locks, the server MUST return an error when a client requests a shared write lock.

6.4 Lock Creator and Privileges

A lock is associated with the principal who created the lock. Only principals with the appropriate lock token can unlock a resource. This ensures that the lock creator has control over the lock's lifecycle.

The principal creating a lock needs to have privileges to create locks on the resource. The specific privilege requirements are determined by the server's access control policy.

6.5 Lock Tokens

A lock token is a URL that uniquely identifies a lock. Lock tokens typically use the opaquelocktoken: URI scheme (see Appendix C).

Lock Token Characteristics:

• Global Uniqueness: Each lock token is globally unique
• Unpredictability: Lock tokens should be unpredictable to prevent unauthorized access
• URL Format: Lock tokens are valid URLs

Example Lock Token:

opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Clients submit lock tokens by:

• Including the lock token in the If header
• Including the lock token in the Lock-Token header (for UNLOCK method only)

6.6 Lock Timeout

Locks have a limited lifetime. The server assigns a timeout value to each lock, after which the lock expires automatically.

Timeout Characteristics:

• Clients can suggest a timeout value in the Timeout request header
• Servers can ignore the client's suggestion and assign their own timeout value
• Servers MUST return the actual timeout value in the lock response
• Clients can extend the lock's lifetime by refreshing the lock

Timeout Format:

Timeout: Second-4100
Timeout: Infinite

Best Practices:

• Servers SHOULD allow clients to refresh locks
• Clients SHOULD periodically refresh long-term locks
• Clients SHOULD unlock resources when editing is complete

6.7 Lock Capability Discovery

Before attempting to lock a resource, clients can discover the server's locking capabilities using the OPTIONS method. The DAV header in the response indicates the server's WebDAV compliance class, which includes locking support.

6.8 Active Lock Discovery

Clients can discover active locks on a resource using the PROPFIND method to retrieve the DAV:lockdiscovery property. This property contains information about all active locks on the resource, including lock type, scope, depth, owner, timeout, and lock token.