11. Status Code Extensions to HTTP/1.1 (Estensioni dei codici di stato per HTTP/1.1)

I seguenti codici di stato sono aggiunti a quelli definiti in HTTP/1.1 [RFC2616].

11.1 207 Multi-Status (Multi-Stato)

Il codice di stato 207 (Multi-Status, Multi-Stato) fornisce lo stato per multiple operazioni indipendenti (vedere Sezione 13 per ulteriori informazioni).

11.2 422 Unprocessable Entity (Entità non elaborabile)

Il codice di stato 422 (Unprocessable Entity, Entità non elaborabile) significa che il server comprende il tipo di contenuto dell'entità di richiesta (quindi un codice di stato 415(Unsupported Media Type) è inappropriato), e la sintassi dell'entità di richiesta è corretta (quindi un codice di stato 400 (Bad Request) è inappropriato) ma non è stato in grado di elaborare le istruzioni contenute. Ad esempio, questa condizione di errore può verificarsi se un corpo di richiesta XML contiene istruzioni XML ben formate (cioè sintatticamente corrette), ma semanticamente errate.

11.3 423 Locked (Bloccato)

Il codice di stato 423 (Locked, Bloccato) significa che la risorsa sorgente o destinazione di un metodo è bloccata. Questa risposta DOVREBBE contenere un codice di precondizione o postcondizione appropriato, come 'lock-token-submitted' o 'no-conflicting-lock'.

11.4 424 Failed Dependency (Dipendenza fallita)

Il codice di stato 424 (Failed Dependency, Dipendenza fallita) significa che il metodo non ha potuto essere eseguito sulla risorsa perché l'azione richiesta dipendeva da un'altra azione e quell'azione è fallita. Ad esempio, se un comando in un metodo PROPPATCH fallisce, allora, come minimo, anche il resto dei comandi fallirà con 424 (Failed Dependency).

11.5 507 Insufficient Storage (Archiviazione insufficiente)

Il codice di stato 507 (Insufficient Storage, Archiviazione insufficiente) significa che il metodo non ha potuto essere eseguito sulla risorsa perché il server non è in grado di memorizzare la rappresentazione necessaria per completare con successo la richiesta. Questa condizione è considerata temporanea. Se la richiesta che ha ricevuto questo codice di stato era il risultato di un'azione utente, la richiesta NON DEVE essere ripetuta fino a quando non viene richiesta da un'azione utente separata.

12. Use of HTTP Status Codes (Uso dei codici di stato HTTP)

Questi codici HTTP non sono ridefiniti, ma il loro uso è in qualche modo esteso dai metodi e dai requisiti WebDAV. In generale, molti codici di stato HTTP possono essere usati in risposta a qualsiasi richiesta, non solo nei casi descritti in questo documento. Si noti anche che i server WebDAV sono noti per usare risposte di reindirizzamento di livello 300 (e i primi test di interoperabilità hanno trovato client non preparati a vedere quelle risposte). Una risposta di livello 300 NON DEVE essere usata quando il server ha creato una nuova risorsa in risposta alla richiesta.

12.1 412 Precondition Failed (Precondizione fallita)

Qualsiasi richiesta può contenere un'intestazione condizionale definita in HTTP (If-Match, If-Modified-Since, ecc.) o le intestazioni condizionali "If" o "Overwrite" definite in questa specifica. Se il server valuta un'intestazione condizionale e se quella condizione non si verifica, allora questo codice di errore DEVE essere restituito. D'altra parte, se il client non ha incluso un'intestazione condizionale nella richiesta, allora il server NON DEVE usare questo codice di stato.

12.2 414 Request-URI Too Long (URI di richiesta troppo lungo)

Questo codice di stato è usato in HTTP 1.1 solo per Request-URIs, non per URI in altre posizioni.

13. Multi-Status Response (Risposta Multi-Stato)

Una risposta Multi-Status trasmette informazioni su multiple risorse in situazioni in cui potrebbero essere appropriati più codici di stato. Il corpo di 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 usato come codice di stato di risposta complessivo, il destinatario deve consultare i contenuti del corpo di risposta multistatus per ulteriori informazioni sul successo o fallimento dell'esecuzione del metodo. La risposta PUÒ essere usata 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 risorsa individuale. Ogni elemento 'response' DEVE avere un elemento 'href' per identificare la risorsa.

Una risposta Multi-Status usa uno di 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 Sezione 9.6.2). Alcune definizioni di metodi forniscono informazioni sui 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, usando le regole generiche definite nella Sezione 10 di [RFC2616].
Per PROPFIND e PROPPATCH, il formato è stato esteso usando l'elemento 'propstat' invece di 'status', fornendo informazioni sulle proprietà individuali 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 non definito.

13.2 Handling Redirected Child Resources (Gestione delle risorse figlio reindirizzate)

Le risposte di reindirizzamento (300-303, 305 e 307) definite in HTTP 1.1 normalmente prendono 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 questa informazione (vedere Sezione 14.9). I server DEVONO usare 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 risorsa reindirizzata individuale, 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 usati nelle risposte Multi-Status. Questa specifica non definisce il significato di altri codici di stato che potrebbero apparire in queste risposte.