423 Locked

The source or destination resource of a WebDAV method is locked, so the request cannot proceed.

Defined in RFC 4918 §11.3

What 423 means

RFC 4918 (WebDAV) defines 423 to indicate that the resource targeted by a method is locked, typically because an earlier LOCK request established a write lock on it. The lock exists to prevent concurrent modification: while it is held, other clients attempting to write to the same resource are rejected with 423 until the lock is released or the correct lock token is presented.

In practice this appears in WebDAV-based systems: CardDAV and CalDAV servers, SharePoint document libraries, and network shares exposed over WebDAV that macOS Finder or Windows Explorer can mount directly. A common scenario is a document management or CMS system where a file has been "checked out" by one user for editing, and any other client's attempt to PUT, DELETE, or MOVE it is met with 423 until that check-out is released.

423 is more specific than 409 Conflict: 409 describes a general state conflict, while 423 specifically means an active WebDAV lock, established and released through LOCK and UNLOCK, is blocking the operation. Clients that know a resource may be locked are expected to supply the correct lock token via the If header; presenting a missing or incorrect token results in 423 rather than the write silently succeeding.

Common causes

Another client holds a write lock on the resource via a prior WebDAV LOCK request.
The request omits the lock token in the If header that is required to operate on a locked resource.
A document management or CMS system has the file checked out by a different user.
A stale lock token is being reused after the original lock expired or was released server-side.
A parent collection was locked with depth-infinity, which locks every resource beneath it as well.

How to fix a 423

If you are the client (browser user or API caller)

Fetch the current lock token, via PROPFIND or the original LOCK response, and include it in the If header of the write request.
Wait for the lock to be released, or ask the locking user or process to send UNLOCK.
Construct the If header using the lock-token syntax defined in RFC 4918 rather than guessing at a token.
Check whether a parent collection carries a depth-infinity lock that is blocking the specific child resource.

If you run the server

Expose lock status through PROPFIND's lockdiscovery property so clients can detect an existing lock before attempting a write.
Set reasonable lock timeouts so an abandoned lock does not block a resource indefinitely.
Provide an administrative force-unlock path for locks that were never released due to a crashed client.
Log lock acquisition and release events to make lock contention easier to diagnose.

Example

PUT /docs/report.docx HTTP/1.1
Host: dav.example.com
Content-Type: application/octet-stream

HTTP/1.1 423 Locked
Content-Type: application/xml

<?xml version="1.0"?>
<D:error xmlns:D="DAV:">
  <D:lock-token-submitted>
    <D:href>/docs/report.docx</D:href>
  </D:lock-token-submitted>
</D:error>

The PUT omitted the If header carrying the active lock token, so the write is rejected.

Try it live

Our free status responder returns a real HTTP 423 you can point tests, monitors or a browser at.

GET https://mcp.httpstatus.com/status/423