HTTP 423 Locked
Quick reference
| Code | 423 |
|---|---|
| Name | Locked |
| Category | 4xx Client Error |
| Spec | RFC 4918 §11.3 |
| Context | WebDAV locking (RFC 4918 §7) |
What 423 means
HTTP 423 Locked is returned by a WebDAV server when a client attempts to modify (PUT, DELETE, PROPPATCH, MOVE, COPY, LOCK) a resource that is currently locked, and the client did not include a valid lock token in the If: header. The resource is protected by an active lock held by another client or by the same client in a different session.
RFC 4918 §11.3 specifies that the 423 response body should contain a DAV:locked-ancestor or DAV:no-conflicting-lock precondition element identifying the conflict. This allows the client to distinguish between "this exact resource is locked" and "a parent collection is locked, which blocks this operation."
WebDAV locking serves a pessimistic concurrency control role — as opposed to the optimistic ETags approach of standard HTTP. A client takes out a lock before editing, holds it during editing, and releases it when done. This prevents simultaneous edits to the same file, which matters in document authoring workflows where last-write-wins is unacceptable.
Complete LOCK → PUT → UNLOCK flow
# Step 1: Acquire an exclusive write lock
LOCK /documents/budget.xlsx HTTP/1.1
Host: dav.example.com
Timeout: Second-3600
Content-Type: application/xml
<?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>alice@example.com</D:owner>
</D:lockinfo>
HTTP/1.1 200 OK
Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
Content-Type: application/xml
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:lockscope><D:exclusive/></D:lockscope>
<D:depth>0</D:depth>
<D:timeout>Second-3600</D:timeout>
<D:locktoken>
<D:href>urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
# Step 2: Upload the modified file using the lock token
PUT /documents/budget.xlsx HTTP/1.1
Host: dav.example.com
If: (<urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Content-Length: 48291
[binary file content]
HTTP/1.1 204 No Content
# Step 3: Release the lock
UNLOCK /documents/budget.xlsx HTTP/1.1
Host: dav.example.com
Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
HTTP/1.1 204 No Content
The If: header on the PUT proves ownership of the lock. Without it, the PUT returns 423 even if the requesting client is the same one that holds the lock — the server validates the token on every write operation.
Why 423 occurs in practice
Stale client session: A WebDAV client (Windows Network Location, macOS Finder, Cyberduck) acquired a lock but the session terminated abnormally without sending UNLOCK. The lock persists until its timeout expires. Other clients receive 423 until the lock expires or an administrator forcibly removes it.
Missing If: header: A script or automation tool attempts to PUT a file to a DAV collection but does not include the lock token in the If: header. This is a client implementation bug — the script must acquire a lock first, record the token, include it on writes, and release it when done.
Locked parent collection: A client locked a collection with Depth: infinity, which locks all resources in the entire subtree. Any write to any resource in that subtree from another client returns 423 with a DAV:locked-ancestor precondition in the response body.
Lock timeout not refreshed: Locks have a server-specified timeout. A client that holds a lock must refresh it periodically using a LOCK request on the already-locked resource. If the lock times out before the edit completes, the lock is released and the next write attempt returns 423.
Resolving 423 errors
To check which client holds the current lock, send a PROPFIND requesting the DAV:lockdiscovery property:
PROPFIND /documents/budget.xlsx HTTP/1.1 Depth: 0 Content-Type: application/xml <?xml version="1.0" encoding="UTF-8"?> <D:propfind xmlns:D="DAV:"> <D:prop><D:lockdiscovery/></D:prop> </D:propfind>
The response includes the lock owner and remaining timeout. If the owner is unavailable or the lock is stale, an administrator can force-unlock using the server's management interface or by issuing UNLOCK with the lock token (requires server-side admin privileges).
Non-WebDAV uses of 423
Some non-WebDAV APIs return 423 to indicate that a resource is temporarily unavailable due to an application-level lock — for example, a record being edited by another user in a multi-user application, a configuration file being updated by a deployment process, or a database row locked by a transaction. This is not defined by any RFC for non-WebDAV use, but the semantic is descriptive and widely understood.
If your API uses 423 for application-level locking, include the lock owner, lock reason, and estimated unlock time in the response body to give clients actionable information. A Retry-After header indicating when the lock should be released is also useful.
Frequently asked questions
What is the difference between 423 and 409?
423 specifically indicates a WebDAV lock is preventing the operation. 409 indicates a broader state conflict — the request conflicts with the current state of the resource for reasons unrelated to locking (duplicate key, invalid state machine transition, etc.). If a lock is the issue, use 423. For other conflicts, use 409.
Can I unlock a resource locked by another user?
Standard WebDAV allows a lock owner to UNLOCK their own lock. Administrators can unlock any resource using server management tools or by sending UNLOCK with server-level credentials. RFC 4918 does not define a mechanism for non-owners to remove a lock without server-side intervention.
What happens when a DAV lock times out?
The server automatically releases the lock when its Timeout value expires. Any pending writes the lock holder had not yet submitted are lost. The resource becomes available to other clients. The lock holder can no longer submit writes using the expired token and will receive a 412 Precondition Failed (the lock token is no longer valid).
Do browsers send WebDAV LOCK requests?
Standard browser HTTP requests (fetch, XMLHttpRequest) do not send LOCK requests. WebDAV LOCK is used by dedicated DAV clients — file managers, desktop applications, and server-side automation scripts. A browser navigating to a locked resource would receive a 423 only if it attempted a PUT or DELETE through a form or fetch call.