Skip to main content

7. Write Lock

This section describes the write lock, the only lock type defined in this specification. A write lock is a lock that grants the lock owner the right to modify the resource. The lock owner is the principal who created the lock.

7.1 Write Locks and Properties​

While those without a write lock may not alter the content of a resource, they MAY modify the dead properties of the resource. This allows, for example, a principal to add comments to a locked resource without needing write access.

Live properties typically have semantics enforced by the server. The server therefore has discretion over whether and how to allow changes to live properties when a resource is locked. For example, a server MAY allow the modification of live properties even when a resource is locked.

7.2 Avoiding Lost Updates​

The purpose of write locks is to prevent lost updates. A lost update occurs when multiple principals attempt to modify a resource without coordination, resulting in one or more principals' changes being overwritten by subsequent updates.

Write locks provide a serialization mechanism: only the lock holder can modify the locked resource. This prevents the lost update problem by ensuring that modifications occur sequentially rather than concurrently.

Example Lost Update Scenario (without locking):

  1. User A retrieves resource version 1
  2. User B retrieves resource version 1
  3. User A modifies and saves → creates version 2
  4. User B modifies (based on version 1) and saves → creates version 3, overwriting A's changes

With Write Lock:

  1. User A locks the resource
  2. User B attempts to modify → receives 423 Locked error
  3. User A modifies and unlocks
  4. User B can now lock and modify

7.3 Write Locks and Unmapped URLs​

A successful LOCK request on an unmapped URL creates an empty resource that is locked. This mechanism allows clients to reserve a URL before the resource content is created.

When a locked empty resource is created:

  • The resource has no content (zero-length entity)
  • The resource is locked with the specified lock
  • Subsequent PUT or MKCOL can add content to the resource
  • The lock token must be submitted with the PUT or MKCOL request

This "lock-null resource" mechanism is described in detail in Appendix D.

7.4 Write Locks and Collections​

A write lock on a collection locks the collection resource itself, preventing modifications to the collection's membership (addition or removal of internal members).

When a depth infinity lock is applied to a collection:

  • The collection itself is locked
  • All internal members are locked
  • All descendant resources are locked recursively
  • New members added to the collection are automatically locked

Lock Inheritance: When a new resource is added to a locked collection (with depth infinity), the new resource inherits the lock from the parent collection.

Example:

Collection /folder/ is locked with Depth: infinity
- Cannot add new members to /folder/
- Cannot modify /folder/file1.txt
- Cannot delete /folder/subfolder/
- Cannot modify /folder/subfolder/file2.txt

7.5 Write Locks and the If Request Header​

Clients submit lock tokens using the If request header. This header allows conditional execution of methods based on lock token presence.

The If header syntax supports:

  • Single lock tokens
  • Multiple lock tokens (for multiple locks)
  • Tagged lists (associating tokens with specific URLs)
  • NOT conditions (requiring absence of locks)

7.5.1 Example - Write Lock and COPY​

COPY /source HTTP/1.1
Host: example.com
Destination: http://example.com/destination
If: \`http://example.com/destination\` (<opaquelocktoken:token123>)

This request copies /source to /destination, but only if the client holds the lock token for /destination.

7.5.2 Example - Deleting a Member of a Locked Collection​

DELETE /folder/file.txt HTTP/1.1
Host: example.com
If: \`http://example.com/folder/\` (<opaquelocktoken:folder-token>)

To delete a member of a locked collection, the client must submit the lock token for the collection.

7.6 Write Locks and COPY/MOVE​

The COPY method creates a new resource at the destination. The new resource is NOT automatically locked, even if the source was locked. Locks are not copied.

The MOVE method is semantically equivalent to COPY followed by DELETE. The lock on the source is removed when the resource is moved. The destination is not automatically locked.

If the destination of a COPY or MOVE is locked, the client must submit the appropriate lock token to overwrite the destination.

7.7 Refreshing Write Locks​

Locks have finite lifetimes. To prevent premature lock expiration, clients can refresh locks by submitting a LOCK request with:

  • The same lock token in the If header
  • No request body (or an empty lockinfo element)

The server responds with the new timeout value. Lock refreshing allows long-term editing sessions without lock expiration.

Example Lock Refresh:

LOCK /resource HTTP/1.1
Host: example.com
If: (<opaquelocktoken:token123>)
Timeout: Second-3600

The server extends the lock timeout and returns the new expiration time.

Last updated on