13. Multi-Status Response (Risposta multi-stato)

Una risposta Multi-Status trasmette informazioni su più risorse in situazioni in cui potrebbero essere appropriati più codici di stato. Il corpo della risposta Multi-Status predefinito è un'entità HTTP text/xml o application/xml con un elemento radice 'multistatus'. Ulteriori elementi contengono codici di stato delle serie 200, 300, 400 e 500 generati durante l'invocazione del metodo. I codici di stato della serie 100 NON DOVREBBERO essere registrati in un elemento XML 'response'.

Sebbene '207' sia utilizzato come codice di stato di risposta complessivo, il destinatario deve consultare il contenuto del corpo della risposta multistatus per ulteriori informazioni sul successo o fallimento dell'esecuzione del metodo. La risposta PUÒ essere utilizzata in situazioni di successo, successo parziale e anche di fallimento.

L'elemento radice 'multistatus' contiene zero o più elementi 'response' in qualsiasi ordine, ciascuno con informazioni su una singola risorsa. Ogni elemento 'response' DEVE avere un elemento 'href' per identificare la risorsa.

Una risposta Multi-Status utilizza uno dei due formati distinti per rappresentare lo stato:

Un elemento 'status' come figlio dell'elemento 'response' indica lo stato dell'esecuzione del messaggio per la risorsa identificata nel suo complesso (ad esempio, vedere la sezione 9.6.2). Alcune definizioni di metodi forniscono informazioni su codici di stato specifici che i client dovrebbero essere preparati a vedere in una risposta. Tuttavia, i client DEVONO essere in grado di gestire altri codici di stato, utilizzando le regole generiche definite nella sezione 10 di [RFC2616].
Per PROPFIND e PROPPATCH, il formato è stato esteso utilizzando l'elemento 'propstat' invece di 'status', fornendo informazioni sulle singole proprietà di una risorsa. Questo formato è specifico per PROPFIND e PROPPATCH ed è descritto in dettaglio nelle sezioni 9.1 e 9.2.

13.1. Response Headers (Intestazioni di risposta)

HTTP definisce l'intestazione Location per indicare un URL preferito per la risorsa che è stata indirizzata nel Request-URI (ad esempio, in risposta a richieste PUT riuscite o in risposte di reindirizzamento). Tuttavia, l'uso di questa intestazione crea ambiguità quando ci sono URL nel corpo della risposta, come con Multi-Status. Pertanto, l'uso dell'intestazione Location con la risposta Multi-Status è intenzionalmente indefinito.

13.2. Handling Redirected Child Resources (Gestione delle risorse figlie reindirizzate)

Le risposte di reindirizzamento (300-303, 305 e 307) definite in HTTP 1.1 normalmente richiedono un'intestazione Location per indicare il nuovo URI per la singola risorsa reindirizzata dal Request-URI. Le risposte Multi-Status contengono molti indirizzi di risorse, ma la definizione originale in [RFC2518] non aveva alcun posto per il server per fornire il nuovo URI per le risorse reindirizzate. Questa specifica definisce un elemento 'location' per queste informazioni (vedere la sezione 14.9). I server DEVONO utilizzare questo nuovo elemento con le risposte di reindirizzamento in Multi-Status.

I client che incontrano risorse reindirizzate in Multi-Status NON DEVONO fare affidamento sulla presenza dell'elemento 'location' con un nuovo URI. Se l'elemento non è presente, il client PUÒ riemettere la richiesta alla singola risorsa reindirizzata, perché la risposta a quella richiesta può essere reindirizzata con un'intestazione Location contenente il nuovo URI.

13.3. Internal Status Codes (Codici di stato interni)

Le sezioni 9.2.1, 9.1.2, 9.6.1, 9.8.3 e 9.9.2 definiscono vari codici di stato utilizzati nelle risposte Multi-Status. Questa specifica non definisce il significato di altri codici di stato che potrebbero apparire in queste risposte.