Cos'e HTTP 207 Multi-Status
Il codice HTTP 207 Multi-Status e definito nella RFC 4918 come parte del protocollo WebDAV. Permette al server di restituire più codici di stato in una singola risposta, ciascuno relativo a una risorsa diversa coinvolta nell'operazione. E fondamentale quando un comando opera su una collezione di file o cartelle e ogni elemento puo avere esito diverso.
Quando si usa il 207
Tipici scenari WebDAV che generano 207:
- PROPFIND: richiesta delle proprietà di un'albero di risorse.
- PROPPATCH: modifica simultanea di più proprietà.
- COPY/MOVE: spostamento ricorsivo di directory.
- DELETE ricorsivo: cancellazione di alberi.
- LOCK/UNLOCK: blocco di risorse multiple.
Struttura della risposta XML
Il body e sempre XML con namespace DAV:
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>/files/doc1.txt</D:href>
<D:status>HTTP/1.1 200 OK</D:status>
</D:response>
<D:response>
<D:href>/files/locked.txt</D:href>
<D:status>HTTP/1.1 423 Locked</D:status>
</D:response>
</D:multistatus>Codici di stato annidati
All'interno di <D:status> il server puo riportare qualsiasi codice HTTP: 200, 201, 403, 404, 423 Locked, 424 Failed Dependency. La risposta esterna resta sempre 207 indipendentemente dagli esiti interni.
Esempio: PROPFIND su una cartella
Quando un client come Cyberduck o Windows Explorer naviga una share WebDAV, invia PROPFIND con Depth 1. Il server elenca tutti i figli e per ognuno restituisce proprietà come dimensione, data ultima modifica, content-type. Se l'utente non ha permessi su un sotto-elemento, viene incluso con status 403 senza far fallire l'intera richiesta.
Failed Dependency (424)
Spesso il 207 si combina con il 424 Failed Dependency: se un'operazione su una risorsa dipende dal successo su un'altra che ha fallito, il client riceve 424 per quella e il codice originale per la dipendenza fallita. Esempio: COPY ricorsivo dove la cartella padre non e copiabile.
Implementazione server
Server WebDAV come Apache mod_dav, Nginx WebDAV module, SabreDAV (PHP) e nephele.js (Node) gestiscono il 207 in modo trasparente. Per implementazioni custom occorre:
- Parsare le proprietà richieste dal body XML PROPFIND.
- Iterare ricorsivamente sull'albero con depth control.
- Costruire l'XML multistatus rispettando il namespace DAV.
- Settare
Content-Type: application/xml; charset=utf-8.
Compatibilità con client REST tradizionali
I client HTTP non WebDAV vedono il 207 come un 2xx generico ma non sanno interpretare il body. Per questo motivo il 207 viene usato anche in API custom: la sua semantica di "successo parziale" si presta a operazioni batch su collezioni di risorse, come bulk update o import di massa.
Esempio: COPY ricorsivo con conflitti
Quando un client esegue COPY /source/folder HTTP/1.1 Destination: /dest/folder Depth: infinity su una struttura con permessi misti, alcune risorse possono essere copiate, altre no. Il server itera nell'albero, esegue la copia dove possibile e raccoglie gli errori. Il risultato e un 207 dove ogni sub-elemento appare con il proprio status: 201 Created per i successi, 403 Forbidden per gli accessi negati, 423 Locked per quelli in uso. Il client puo così sapere precisamente cosa e stato copiato e cosa no, decidendo se compensare o ripetere selettivamente.
Performance e payload size
I body XML del 207 possono diventare molto grandi quando si applicano a collezioni con migliaia di elementi (es. PROPFIND su archivi documentali enterprise). Server avanzati implementano streaming XML: invece di costruire l'intero documento in memoria, scrivono i tag mano a mano che processano le risorse. Questo permette di gestire alberi enormi senza saturare la RAM e di iniziare a inviare la risposta quasi immediatamente.
Differenza con 200 e 4xx
Un'endpoint REST tradizionale ritorna 200 oppure 4xx per l'intera operazione. Con il 207 il livello di granularita scende alla singola risorsa, permettendo al client di sapere esattamente cosa e andato bene e cosa no senza ricorrere a polling o richieste separate.
Esempio COPY ricorsivo
Quando un client esegue COPY ricorsivo su una struttura con permessi misti, alcune risorse possono essere copiate, altre no. Il server itera nell'albero, esegue la copia dove possibile e raccoglie gli errori. Il risultato e un 207 dove ogni sub-elemento appare con il proprio status: 201 Created per i successi, 403 Forbidden per gli accessi negati, 423 Locked per quelli in uso. Il client puo così sapere precisamente cosa e stato copiato e cosa no.
Performance e payload size
I body XML del 207 possono diventare molto grandi quando si applicano a collezioni con migliaia di elementi. Server avanzati implementano streaming XML: invece di costruire l'intero documento in memoria, scrivono i tag mano a mano che processano le risorse. Questo permette di gestire alberi enormi senza saturare la RAM e di iniziare a inviare la risposta quasi immediatamente.
Limiti del 207 in pratica
Pur essendo elegante, il 207 ha limiti pratici: tool di monitoring HTTP generici aggregano gli status di alto livello e potrebbero classificare un 207 come successo anche se al suo interno ci sono molti errori. Per metriche significative occorrono parser custom che analizzano il body. Inoltre, alcuni client REST molto semplici non interpretano XML multistatus.
Best practice
Includere sempre uno status code esplicito per ogni response element. Documentare formalmente gli schema XML nelle API docs. Loggare i codici interni per analytics. Considerare un fallback JSON per client moderni che preferiscono parsing più leggero rispetto a XML namespace-aware.
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.