What it does
UNLOCK releases a lock previously established with LOCK, identified by the lock token the client presents. Once released, other clients are free to LOCK the resource themselves, and writes no longer require presenting that token.
Semantics
| Property | Value | Why it matters |
|---|---|---|
| Safe | No | Changes the resource's lock state |
| Idempotent | Yes | Unlocking an already-unlocked resource (or repeating the request) leaves the same end state — no lock |
| Cacheable | No | Not a read |
| Request body | No | The lock token is passed via the Lock-Token header, not a body |
| Response body | No | Success is signaled purely by status code |
Syntax & example request
UNLOCK /files/report.pdf HTTP/1.1
Host: dav.example.com
Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>
HTTP/1.1 204 No Content
curl example
curl -X UNLOCK https://dav.example.com/files/report.pdf \
-H "Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>"
Common status codes returned
- 204 No Content — lock released successfully → see 204
- 423 Locked — the presented token doesn't match the active lock, or the caller isn't the lock owner → see 423
UNLOCK vs LOCK expiration
| UNLOCK | Timeout expiration | |
|---|---|---|
| Trigger | Explicit client request | Lock's Timeout duration elapses |
| Requires the token | Yes | N/A — happens automatically |
| Typical use | Client finished editing, releases deliberately | Safety net for abandoned/crashed clients |
Well-behaved clients UNLOCK explicitly when done; the Timeout mechanism exists specifically as a fallback for clients that don't (crash, lose connectivity, forget).
Real-world usage
- WebDAV clients releasing a document lock after a user finishes editing and saves/closes a file
- Cleanup scripts explicitly releasing locks rather than waiting for timeout expiration, to let other clients proceed immediately
Security considerations
Servers must verify the presented Lock-Token actually matches the resource's active lock — and ideally that the requester is the original lock owner — before honoring an UNLOCK, otherwise any client that can guess or intercept a lock token could prematurely release someone else's lock and open a window for a conflicting write.
FAQ
Can anyone UNLOCK a resource, or only the lock holder?
Only the party presenting the correct, matching lock token can UNLOCK — the token functions as proof of ownership, similar to a session credential scoped to that lock.
What happens if I never call UNLOCK?
The lock remains active until its Timeout expires (set when the lock was created via LOCK), after which the server releases it automatically as if UNLOCK had been called.
Is UNLOCK idempotent?
Yes — calling UNLOCK on a resource that's already unlocked (or repeating the same UNLOCK call) leaves the resource in the same unlocked state either way, satisfying the idempotency definition even though the second call may return a different status if the token's no longer recognized.
Fun fact
UNLOCK is one of the rare WebDAV methods with no XML request body at all — every other WebDAV-defined method (PROPFIND, PROPPATCH, LOCK) communicates structured data via an XML payload, but UNLOCK's entire instruction fits in a single Lock-Token header, since there's nothing left to specify beyond "which lock, exactly, do you want released."