HTTP 423 Locked: WebDAV explained

Cos'e HTTP 423 Locked

Il codice HTTP 423 Locked, definito dalla RFC 4918 (WebDAV), indica che la risorsa richiesta o di destinazione e attualmente bloccata e il metodo richiesto non puo essere applicato. E il meccanismo cardine del locking WebDAV, che previene modifiche concorrenti su file condivisi.

Il metodo LOCK

WebDAV introduce due metodi specifici:

• LOCK: acquisisce un lock su una risorsa.
• UNLOCK: rilascia il lock.

Esempio LOCK:

LOCK /documents/contratto.docx HTTP/1.1
Timeout: Second-600
Depth: 0
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><D:href>mailto:alice@example.com</D:href></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>...info...</D:activelock>
  </D:lockdiscovery>
</D:prop>

Quando si verifica 423

Il server risponde 423 quando un client tenta di modificare (PUT, DELETE, MOVE, ecc) una risorsa lockata senza fornire un Lock-Token valido:

PUT /documents/contratto.docx HTTP/1.1
Content-Type: application/octet-stream

[contenuto file]

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

<D:error xmlns:D="DAV:">
  <D:lock-token-submitted>
    <D:href>/documents/contratto.docx</D:href>
  </D:lock-token-submitted>
</D:error>

Header If con lock token

Per dichiarare al server di essere autorizzato a modificare una risorsa lockata, il client invia il token nell'header If:

PUT /documents/contratto.docx HTTP/1.1
If: (<urn:uuid:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)
Content-Type: application/octet-stream

[contenuto file]

HTTP/1.1 204 No Content

Lock scope: shared vs exclusive

Due tipi di lock:

• Exclusive: solo il proprietario puo modificare. Altri lock vengono rifiutati con 423.
• Shared: più utenti possono detenere lock contemporaneamente, ma scrittori non lockati ricevono 423.

Depth e lock ricorsivi

L'header Depth: infinity in LOCK applica il lock all'intero albero. Quindi:

LOCK /folder/ HTTP/1.1
Depth: infinity

# Tutti i file dentro /folder/ sono ora bloccati transitivamente

Tentativi di scrittura su qualsiasi figlio (anche grandi alberi) ricevono 423.

Timeout dei lock

I lock hanno scadenza per evitare deadlock quando client si disconnettono:

Timeout: Second-600   # 10 minuti
Timeout: Infinite     # mai scade (sconsigliato)

Client devono refreshare il lock con LOCK senza body prima della scadenza. Alla scadenza, il lock si rilascia automaticamente.

Implementazione client

Microsoft Office (Word, Excel) usa WebDAV per editing su SharePoint. Quando apri un documento, il client emette LOCK; chiudendolo, UNLOCK. Se due utenti aprono lo stesso file:

• Primo utente: LOCK OK.
• Secondo utente: LOCK su file già lockato -> 423.
• Office mostra "File in uso da [proprietario]".

423 e Failed Dependency (424)

Operazioni multi-resource come COPY/MOVE possono restituire 207 con 423 e 424 mixed:

HTTP/1.1 207 Multi-Status

<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/file-locked.txt</D:href>
    <D:status>HTTP/1.1 423 Locked</D:status>
  </D:response>
  <D:response>
    <D:href>/file-dependent.txt</D:href>
    <D:status>HTTP/1.1 424 Failed Dependency</D:status>
  </D:response>
</D:multistatus>

423 fuori da WebDAV

Alcune API REST riusano 423 in senso esteso: account lockati per troppi tentativi falliti, risorse temporaneamente bloccate da manutenzione, file in transcoding non modificabili. Pratica accettata anche se nasce in WebDAV.

Server WebDAV più comuni

• Apache mod_dav + mod_dav_fs: implementazione classica filesystem-based.
• Nginx WebDAV module: nativo per file statici, no lock avanzati.
• SabreDAV (PHP): framework per WebDAV custom.
• Nephele (Node): WebDAV server moderno.
• SharePoint, Nextcloud, ownCloud: implementazioni complete enterprise.

Sicurezza lock

I lock token devono essere imprevedibili (UUID random) per prevenire hijack. RFC 4918 raccomanda almeno 128 bit di entropy. Inoltre, server dovrebbero validare che il client che lockka sia lo stesso che fa unlock (tramite auth).

Best practice

• Timeout brevi (5-15 minuti) per evitare blocchi indefiniti da client disconnessi.
• UNLOCK esplicito quando l'utente chiude il file.
• UI che mostra chi detiene il lock (owner XML).
• Mecanismo "force unlock" per amministratori.

WebDAV in Microsoft Office

Office utilizza WebDAV per editing collaborativo su SharePoint. Quando apri un .docx, Office emette LOCK con timeout 600 secondi e refresh periodico. Chiusura del file invia UNLOCK. Bug noto: Office che crasha non rilascia il lock, lasciando file "bloccato" per il timeout intero. Soluzione: ridurre timeout server-side a 5 minuti.

423 oltre WebDAV

API REST moderne riusano 423 in senso esteso: account temporaneamente bloccati (troppi login falliti), risorse durante manutenzione, transcoding video in corso. Body informativo aiuta il client a decidere: ritentare dopo N minuti? Mostra messaggio all'utente?

Lock token security

I lock token devono essere unpredictable (UUIDv4 raccomandato). Token deboli permettono lock hijack: attacker che intercetta un lock token puo rubarne il controllo. RFC 4918 raccomanda 128 bit di entropy minimi.

Shared lock semantics

Shared lock permette più utenti di tenere lock contemporaneamente, indicando "sto leggendo questo file, non sovrascriverlo aggressivamente". Scrittori non-lockati ricevono 423. Utile per scenari read-heavy con occasional write coordinato.

Implementazione filesystem

Apache mod_dav usa un database integrato (mod_dav_fs lock DB) per tracciare lock. Implementazioni cloud (SharePoint) usano DB distribuiti con coerenza forte. Performance critical: lookup di lock deve essere veloce (sub-millisecond) per non rallentare ogni write.

Discovery dei lock detenuti

PROPFIND con proprietà D:lockdiscovery ritorna info sui lock attivi: chi detiene, scadenza, scope. UI di document management mostra queste info come "In uso da Mario Rossi fino alle 15:30".

Force unlock per admin

Quando un lock e abbandonato (utente disconnesso, browser chiuso) prima del timeout, admin deve poter rilasciare manualmente. Standard WebDAV non lo definisce: ogni implementazione lo aggiunge come API custom (PUT con header speciale, endpoint /admin/unlock).

Lock granularity

Lock per file singolo vs intera cartella (Depth: infinity). Granularita fine permette più concorrenza ma overhead maggiore. Granularita grossa riduce throughput collaborativo ma e semplice da gestire.

423 in scenari REST

API non-WebDAV che riusano 423: account lockato dopo failed logins, risorsa in maintenance mode, file in transcoding. Header Retry-After indica quando ritentare. Body informativo aiuta utente capire perché e bloccato.

Hai bisogno di aiuto?

Se il tuo sito mostra errori HTTP, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.