LOCK HTTP Method — Reference

What it does

LOCK reserves a resource for exclusive or shared editing, preventing (or coordinating) concurrent modification by other clients — WebDAV's answer to "two people editing the same document at once." A successful LOCK returns a lock token, which the client must present on subsequent write requests (PUT, PROPPATCH, DELETE, MOVE) to prove it holds the lock.

This is a genuinely different concurrency-control mechanism from HTTP's ETag/If-Match approach used elsewhere — instead of optimistic concurrency (try the write, fail if something changed), LOCK is pessimistic: reserve the resource first, then write with confidence nobody else can.

Semantics

Property	Value	Why it matters
Safe	No	Changes the resource's lock state
Idempotent	No	Calling LOCK again (a "refresh") extends the timeout rather than being a no-op — repeated calls have a cumulative effect on lock duration
Cacheable	No	Not a read
Request body	Yes	XML specifying lock type (exclusive/shared), scope, and owner info
Response body	Yes	XML containing the lock token and details

Syntax & example request

LOCK /files/report.pdf HTTP/1.1
Host: dav.example.com
Timeout: Second-3600
Content-Type: application/xml

<?xml version="1.0"?>
<D:lockinfo xmlns:D="DAV:">
  <D:lockscope><D:exclusive/></D:lockscope>
  <D:locktype><D:write/></D:locktype>
  <D:owner>[email protected]</D:owner>
</D:lockinfo>

HTTP/1.1 200 OK
Content-Type: application/xml
Lock-Token: <urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>

<D:prop xmlns:D="DAV:">
  <D:lockdiscovery>
    <D:activelock>
      <D:locktype><D:write/></D:locktype>
      <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>

curl example

curl -X LOCK https://dav.example.com/files/report.pdf \
  -H "Content-Type: application/xml" \
  -H "Timeout: Second-3600" \
  --data '<?xml version="1.0"?><D:lockinfo xmlns:D="DAV:"><D:lockscope><D:exclusive/></D:lockscope><D:locktype><D:write/></D:locktype></D:lockinfo>'

Common status codes returned

200 OK — lock refreshed on an already-locked resource → see 200
201 Created — lock created on a resource that didn't exist before (LOCK can create an empty locked resource) → see 201
423 Locked — resource is already locked by someone else → see 423

Shared vs exclusive locks

Lock type	Meaning
Exclusive	Only the lock holder can write; everyone else is blocked
Shared	Multiple clients can hold the same shared lock simultaneously — useful for "several people editing collaboratively, but exclude outsiders" scenarios

Real-world usage

Document management systems (older CMS platforms, some file-sync tools) preventing two users from overwriting each other's edits to the same file
WebDAV clients showing a "locked by another user" indicator when a document is checked out elsewhere

Security considerations

Lock tokens function like bearer credentials for a specific resource — anyone who obtains the token can perform locked-write operations as if they were the original lock holder, so tokens need to be treated with the same care as session tokens (transmitted only over TLS, not logged, not leaked in URLs). Servers should also enforce reasonable lock timeouts — an indefinitely-held lock that the original client abandoned (crashed, lost connectivity) without releasing effectively becomes a permanent denial-of-service against that resource unless timeouts force expiration.

FAQ

Why is LOCK not idempotent?

Calling LOCK again on an already-locked resource (by the same owner, presenting the right token) typically refreshes the lock's timeout rather than being a no-op — so the effect of calling it twice (extended duration) differs from calling it once, which is what disqualifies it from being idempotent by the strict definition.

What happens if a client holding a lock disconnects without releasing it?

The lock persists until its Timeout expires — this is why LOCK requests specify a timeout up front, so abandoned locks eventually release themselves rather than blocking a resource indefinitely.

How does a client prove it holds a lock on a later request?

By including the lock token (returned in the LOCK response's Lock-Token header) in an If header on subsequent write requests to that resource — the server checks the token matches an active lock before allowing the write.

Fun fact

WebDAV's LOCK/UNLOCK pair is one of the few places in core HTTP-adjacent specs where pessimistic concurrency control (reserve first, then write) is standardized — nearly everywhere else in HTTP (ETags, If-Match), the pattern is optimistic (attempt the write, fail cleanly if something changed underneath you).

LOCK