| Codice di stato HTTP | Codice di stato Significato |
|---|
| 100 | Il client deve continuare a inviare richieste. Questa risposta temporanea viene utilizzata per informare il client che una parte della sua richiesta è stata ricevuta dal server e non è stata rifiutata. Il client deve continuare a inviare il resto della richiesta o ignorare questa risposta se la richiesta è completa. Il server deve inviare una risposta finale al client quando la richiesta è completa. |
| 101 | Il server ha compreso la richiesta del client e gli comunicherà, tramite l'intestazione del messaggio Upgrade, di utilizzare un protocollo diverso per completare la richiesta. Dopo aver inviato l'ultima riga vuota di questa risposta, il server passerà ai protocolli definiti nell'intestazione del messaggio Upgrade. Questa operazione va fatta solo se è più vantaggioso passare a un nuovo protocollo. Ad esempio, il passaggio a una nuova versione di HTTP è più vantaggioso rispetto a una versione precedente, oppure il passaggio a un protocollo sincrono e in tempo reale per fornire risorse che sfruttano tali caratteristiche. |
| 102 | I codici di stato, estesi da WebDAV (RFC 2518), indicano che l'elaborazione continuerà. |
| 200 | La richiesta ha avuto successo e l'intestazione della risposta o il corpo dei dati desiderati dalla richiesta saranno restituiti con questa risposta. |
| 201 | La richiesta è stata soddisfatta e una nuova risorsa è stata creata come richiesto dalla richiesta e il suo URI è stato restituito con l'intestazione Location. Se la risorsa richiesta non può essere creata in tempo, verrà restituito "202 Accepted". |
| 202 | Il server ha accettato la richiesta, ma non l'ha ancora elaborata. Così come può essere rifiutata, alla fine la richiesta può essere eseguita o meno. Nel contesto delle operazioni asincrone, non c'è niente di più conveniente che inviare questo codice di stato. Lo scopo di restituire una risposta con un codice di stato 202 è quello di consentire al server di accettare richieste da altri processi (come un'operazione batch che viene eseguita solo una volta al giorno) senza dover mantenere il client connesso al server fino al completamento dell'operazione batch. Una risposta che accetta una richiesta di elaborazione e restituisce un codice di stato 202 DOVREBBE includere nell'entità restituita alcune informazioni che indicano lo stato attuale del processo, nonché un puntatore a un monitor dello stato di elaborazione o a una previsione di stato, in modo che l'utente possa valutare se l'operazione è stata completata. |
| 203 | Il server ha elaborato con successo la richiesta, ma le meta-informazioni dell'intestazione dell'entità restituita non sono un insieme definitivo valido sul server originale, ma una copia proveniente da una parte locale o da terzi. Le informazioni attuali possono essere un sottoinsieme o un superset della versione originale. Ad esempio, i metadati contenenti risorse possono far sì che il server originale conosca la super-informazione. L'uso di questo codice di stato non è obbligatorio ed è appropriato solo se la risposta avrebbe restituito 200 OK senza di esso. |
| 204 | Il server ha elaborato la richiesta con successo, ma non ha bisogno di restituire alcun contenuto fisico e vuole restituire meta-informazioni aggiornate. La risposta può restituire meta-informazioni nuove o aggiornate sotto forma di intestazioni di entità. Se tali intestazioni esistono, devono corrispondere alle variabili richieste. Se il client è un browser, il browser dell'utente DOVREBBE mantenere la pagina su cui è stata inviata la richiesta senza alcuna modifica della visualizzazione del documento, anche se secondo le specifiche le meta-informazioni nuove o aggiornate DOVREBBERO essere applicate al documento nella visualizzazione attiva del browser dell'utente. Poiché la risposta 204 non può contenere alcun corpo del messaggio, termina sempre con la prima riga vuota dopo l'intestazione del messaggio. |
| 205 | Il server ha elaborato con successo la richiesta e non ha restituito nulla. A differenza della risposta 204, tuttavia, la risposta che restituisce questo codice di stato chiede al richiedente di reimpostare la visualizzazione del documento. Questa risposta viene utilizzata principalmente per reimpostare il modulo subito dopo aver accettato l'input dell'utente, in modo che quest'ultimo possa facilmente iniziare un altro input. Come la risposta 204, questa risposta non può contenere alcun corpo del messaggio e termina con la prima riga vuota dopo l'intestazione del messaggio. |
| 206 | Il server ha elaborato con successo parte della richiesta GET. Strumenti di download HTTP come FlashGet o Thunderbolt utilizzano questo tipo di risposta per eseguire download intermittenti o per suddividere un documento di grandi dimensioni in più segmenti di download contemporaneamente. La richiesta deve contenere un'intestazione Range per indicare l'intervallo di contenuti che il client desidera ricevere e può contenere un If-Range come condizione della richiesta. La risposta deve contenere i seguenti campi di intestazione: Content-Range per indicare l'ambito del contenuto restituito in questa risposta; nel caso di un download a più segmenti con un Content-Type di multipart/byteranges, ogni segmento multipart deve contenere un campo Content-Range che indichi l'ambito del contenuto in quel segmento. Se la risposta contiene un Content-Length, il suo valore deve corrispondere al numero reale di byte nell'intervallo di contenuto restituito. data ETag e/o Content-Location, se la stessa richiesta avrebbe dovuto restituire una risposta 200. Expires, Cache-Control e/o Vary, se i loro valori possono essere diversi da altre risposte con le stesse variabili. Expires, Cache-Control e/o Vary, se i loro valori possono essere diversi da quelli di altre risposte precedenti per le stesse variabili. Questa risposta NON DEVE contenere altre intestazioni di entità se la richiesta utilizza la validazione forte della cache If-Range e NON DEVE contenere altre intestazioni di entità se la richiesta utilizza la validazione debole della cache If-Range; in questo modo si evitano incongruenze tra il contenuto dell'entità nella cache e le informazioni aggiornate dell'intestazione dell'entità. Altrimenti, questa risposta DOVREBBE contenere tutti i campi delle intestazioni delle entità che dovrebbero essere restituiti in tutte le risposte 200 che dovrebbero essere restituite. Se le intestazioni ETag o Last-Modified non corrispondono esattamente, la cache lato client DOVREBBE proibire di combinare il contenuto restituito nella risposta 206 con qualsiasi contenuto precedentemente memorizzato nella cache. A qualsiasi cache che non supporta le intestazioni Range e Content-Range è vietato memorizzare nella cache il contenuto restituito dalla risposta 206. |
| 207 | Il codice di stato, come esteso da WebDAV (RFC 2518), significa che il corpo del messaggio successivo sarà un messaggio XML e potrà contenere una serie di codici di risposta separati, a seconda del numero di sotto-richieste precedenti. |
| 300 | La risorsa richiesta ha una serie di messaggi di ritorno alternativi, ciascuno con il proprio indirizzo specifico e con le informazioni di negoziazione determinate dal browser. L'utente o il browser è in grado di selezionare autonomamente un indirizzo preferito per il reindirizzamento. A meno che non si tratti di una richiesta HEAD, la risposta deve includere un'entità che è un elenco di caratteristiche della risorsa e di indirizzi da cui l'utente o il browser può selezionare l'indirizzo di reindirizzamento più appropriato. Il formato di questa entità è determinato dal formato della definizione di Content-Type. Il browser può effettuare automaticamente la selezione più appropriata in base al formato della risposta e alle capacità del browser stesso. Naturalmente, le specifiche RFC 2616 non specificano come tale scelta automatica debba essere effettuata. Se il server stesso ha già una scelta di risposta preferita, l'URI di questa risposta deve essere specificato in Location; il browser può usare questo valore di Location come indirizzo per il reindirizzamento automatico. Inoltre, questa risposta è anche memorizzabile nella cache, a meno che non sia specificato diversamente. |
| 301 | La risorsa richiesta è stata spostata in modo permanente nella nuova posizione e qualsiasi riferimento futuro a essa dovrà utilizzare uno dei diversi URI restituiti in questa risposta. Se possibile, i client con capacità di modifica dei link dovrebbero cambiare automaticamente l'indirizzo richiesto con quello restituito dal server. Anche questa risposta è memorizzabile nella cache, se non diversamente specificato. Il nuovo URI permanente dovrebbe essere restituito nel campo Location della risposta. A meno che non si tratti di una richiesta HEAD, l'entità della risposta dovrebbe contenere un collegamento ipertestuale al nuovo URI e una breve descrizione. Se non si tratta di una richiesta GET o HEAD, al browser è quindi vietato il reindirizzamento automatico, a meno che non sia confermato dall'utente, poiché i termini della richiesta potrebbero cambiare di conseguenza. Nota: per alcuni browser che utilizzano il protocollo HTTP/1.0, quando inviano una richiesta POST e ricevono una risposta 301, la successiva richiesta di reindirizzamento sarà una GET. |
| 302 | La risorsa richiesta ora risponde temporaneamente alla richiesta da un URI diverso. Poiché questo reindirizzamento è temporaneo, il client deve continuare a inviare le richieste future all'indirizzo originale. Questa risposta è memorizzabile nella cache solo se specificata in Cache-Control o Expires. Il nuovo URI temporaneo deve essere restituito nel campo Location della risposta. A meno che non si tratti di una richiesta HEAD, l'entità della risposta deve contenere un collegamento ipertestuale al nuovo URI e una breve descrizione. Se non si tratta di una richiesta GET o HEAD, al browser è vietato il reindirizzamento automatico, a meno che non sia confermato dall'utente, poiché i termini della richiesta potrebbero cambiare di conseguenza. Nota: sebbene le specifiche RFC 1945 e RFC 2068 non consentano al client di cambiare il metodo della richiesta durante il reindirizzamento, molti browser esistenti trattano la risposta 302 come una risposta 303 e utilizzano GET per accedere all'URI specificato nella posizione, ignorando il metodo della richiesta originale. I codici di stato 303 e 307 sono stati aggiunti per chiarire quale risposta il server si aspetta dal client. |
| 303 | La risposta alla richiesta corrente può essere trovata in un altro URI e il client deve accedere a tale risorsa utilizzando GET. Questo metodo esiste principalmente per consentire il reindirizzamento dell'output della richiesta POST attivata da script a una nuova risorsa. Questo nuovo URI non è un riferimento alternativo alla risorsa originale. Inoltre, la risposta 303 non può essere messa in cache. Naturalmente, la seconda richiesta (reindirizzamento) può essere messa in cache. Il nuovo URI dovrebbe essere restituito nel campo Location della risposta. A meno che non si tratti di una richiesta HEAD, l'entità della risposta dovrebbe contenere un collegamento ipertestuale al nuovo URI e una breve descrizione. Nota: Molti browser precedenti alle versioni HTTP/1.1 non comprendono correttamente lo stato 303. Se è necessario interagire con questi browser, il codice di stato 302 dovrebbe essere sufficiente, poiché la maggior parte dei browser elabora le risposte 302 esattamente nel modo in cui la specifica di cui sopra richiede al client di elaborare una risposta 303. |
| 304 | Il server DOVREBBE restituire questo codice di stato se il client invia una richiesta GET condizionale che è stata autorizzata e il contenuto del documento (dall'ultima visita o in base alle condizioni della richiesta) non è cambiato.304 Le risposte non possono contenere un corpo del messaggio e quindi terminano sempre con la prima riga vuota dopo l'intestazione del messaggio. La risposta DEVE contenere le seguenti intestazioni: Data, a meno che il server non disponga di un orologio. Se un server senza orologio segue queste regole, il server proxy e il client possono aggiungere autonomamente il campo Data all'intestazione della risposta in arrivo (come specificato nella RFC 2068) e il meccanismo di caching funzionerà correttamente.ETag e/o Content-Location, se la stessa richiesta avrebbe restituito una risposta 200.Expires Expires, Cache-Control e/o Vary, se il valore può essere diverso da quello corrispondente ad altre risposte precedenti per la stessa variabile. Se questa richiesta di risposta utilizza una convalida forte della cache, allora questa risposta non deve contenere altre intestazioni di entità; in caso contrario (ad esempio, una richiesta GET condizionale utilizza una convalida debole della cache), a questa risposta è vietato contenere altre intestazioni di entità; in questo modo si evitano incongruenze tra il contenuto dell'entità nella cache e le informazioni aggiornate dell'intestazione dell'entità. Se una risposta 304 indica che un'entità non è attualmente nella cache, il sistema di cache deve ignorare la risposta e ripetere la richiesta senza la restrizione. Se viene ricevuta una risposta 304 che richiede l'aggiornamento di una voce della cache, il sistema di cache DEVE aggiornare l'intera voce per riflettere i valori di tutti i campi aggiornati nella risposta. |
| 305 | La risorsa richiesta deve essere accessibile attraverso il proxy specificato. il campo Location fornirà informazioni sull'URI in cui si trova il proxy specificato. il destinatario dovrà inviare ripetutamente una richiesta separata per accedere alla risorsa attraverso questo proxy. Solo il server originale può creare una risposta 305. Nota: Dalla RFC 2068 non è chiaro se una risposta 305 sia destinata al reindirizzamento di una singola richiesta e possa essere creata solo dal server originale. Ignorare queste restrizioni potrebbe portare a gravi conseguenze per la sicurezza. |
| 306 | Nell'ultima versione della specifica, il codice di stato 306 non viene più utilizzato. |
| 307 | La risorsa richiesta ora risponde temporaneamente alla richiesta da un URI diverso. Poiché questi reindirizzamenti sono temporanei, i client dovrebbero continuare a inviare le richieste future all'indirizzo originale. Questa risposta è memorizzabile nella cache solo se specificata in Cache-Control o Expires. Il nuovo URI temporaneo deve essere restituito nel campo Location della risposta. A meno che non si tratti di una richiesta HEAD, l'entità della risposta dovrebbe contenere un collegamento ipertestuale al nuovo URI e una breve descrizione. Poiché alcuni browser non riconoscono la risposta 307, è necessario aggiungere le informazioni di cui sopra, in modo che l'utente possa capire e richiedere l'accesso al nuovo URI. Se non si tratta di una richiesta GET o HEAD, il browser vieta il reindirizzamento automatico, a meno che non sia confermato dall'utente, perché le condizioni della richiesta possono cambiare. |
| 400 | 1. Si è verificato un errore semantico e la richiesta corrente non può essere compresa dal server. A meno che non venga modificata, il client non deve inviare ripetutamente questa richiesta. 2. I parametri della richiesta sono sbagliati. |
| 401 | La richiesta corrente richiede l'autenticazione dell'utente. La risposta deve contenere un'intestazione WWW-Authenticate per la risorsa richiesta per richiedere le informazioni sull'utente. Il client può inviare ripetutamente una richiesta che contenga le informazioni appropriate dell'intestazione Authorisation. Se la richiesta corrente contiene già credenziali di autorizzazione, la risposta 401 significa che il server verifica che tali credenziali sono state rifiutate. Se la risposta 401 contiene la stessa domanda di autenticazione della risposta precedente e il browser ha già tentato l'autenticazione almeno una volta, il browser DOVREBBE presentare all'utente le informazioni sull'entità contenute nella risposta, poiché queste informazioni sull'entità possono contenere informazioni diagnostiche rilevanti. Vedere RFC 2617. |
| 402 | Questo codice di stato è riservato per eventuali requisiti futuri. |
| 403 | Il server ha compreso la richiesta ma rifiuta di eseguirla. A differenza di una risposta 401, l'autenticazione non fornisce alcun aiuto e questa richiesta non deve essere ripresentata. Se non si tratta di una richiesta HEAD e il server vuole poter parlare chiaramente del motivo per cui la richiesta non può essere eseguita, il motivo del rifiuto deve essere descritto all'interno dell'entità. Naturalmente il server può anche restituire una risposta 404 se non vuole fornire alcuna informazione al client. |
| 404 | La richiesta è fallita, la risorsa richiesta non è stata trovata sul server. Non ci sono informazioni per dire all'utente se la situazione è temporanea o permanente. Se il server è a conoscenza della situazione, dovrebbe utilizzare il codice di stato 410 per informare l'utente che la vecchia risorsa non è disponibile in modo permanente a causa di qualche meccanismo di configurazione interna e che non è disponibile un reindirizzamento. 404 è ampiamente utilizzato quando il server non vuole rivelare il motivo per cui la richiesta è stata rifiutata o quando non sono disponibili altre risposte adeguate. |
| 405 | Il metodo di richiesta specificato nella riga della richiesta non può essere utilizzato per richiedere la risorsa corrispondente. La risposta deve restituire un'intestazione Allow che indica l'elenco dei metodi di richiesta accettabili per la risorsa corrente. Dato che i metodi PUT e DELETE scrivono sulla risorsa sul server, la maggior parte dei server web non supporta questi metodi di richiesta o non li consente per impostazione predefinita e restituirà un errore 405 per tali richieste. |
| 406 | Le caratteristiche del contenuto della risorsa richiesta non soddisfano le condizioni dell'intestazione della richiesta e non è possibile generare un'entità di risposta. A meno che non si tratti di una richiesta HEAD, la risposta dovrebbe restituire un'entità contenente un elenco di caratteristiche e indirizzi di entità da cui l'utente o il browser possono selezionare la più appropriata. Il formato dell'entità è determinato dal tipo di media definito nell'intestazione Content-Type. I browser possono fare le loro scelte migliori in base al formato e alle loro capacità. Tuttavia, la specifica non definisce alcun criterio per effettuare tali scelte automatiche. |
| 407 | Simile alla risposta 401, ma il client DEVE autenticarsi presso il server proxy. Il server proxy DEVE restituire un Proxy-Authenticate per l'interrogazione dell'identità. Il client PUÒ restituire un'intestazione Proxy-Authorization per l'autenticazione. Vedere RFC 2617. |
| 408 | Timeout della richiesta. Il client non ha completato l'invio di una richiesta entro il tempo che il server era disposto ad attendere. Il client può ripresentare la richiesta in qualsiasi momento senza apportare alcuna modifica. |
| 409 | Non è stato possibile completare la richiesta a causa di un conflitto con lo stato attuale della risorsa richiesta. Questo codice può essere utilizzato solo se si ritiene che l'utente sia in grado di risolvere il conflitto e ripresentare una nuova richiesta. La risposta deve contenere informazioni sufficienti per consentire all'utente di scoprire l'origine del conflitto. I conflitti si verificano tipicamente nell'elaborazione delle richieste PUT. Ad esempio, in un ambiente di controllo delle versioni, se le informazioni sulla versione allegate a una PUT inviata per modificare una particolare risorsa sono in conflitto con una richiesta precedente (di terzi), il server dovrebbe restituire un errore 409, informando l'utente che la richiesta non ha potuto essere completata. In questo caso, l'entità di risposta conterrà probabilmente un confronto delle differenze tra le due versioni in conflitto, in modo che l'utente possa inviare nuovamente la nuova versione dopo la fusione. |
| 410 | La risorsa richiesta non è più disponibile sul server e non ha un indirizzo di inoltro noto. Questa condizione deve essere considerata permanente. Se possibile, i client con capacità di modifica dei link dovrebbero rimuovere tutti i riferimenti a questo indirizzo con il permesso dell'utente. Se il server non sa o non può determinare se questa condizione è permanente, si deve usare un codice di stato 404. Se non diversamente indicato, questa risposta è memorizzabile nella cache.410 Lo scopo della risposta è principalmente quello di aiutare il webmaster nella manutenzione del sito, informando l'utente che la risorsa non è più disponibile e che il proprietario del server desidera che anche tutte le connessioni remote a questa risorsa siano rimosse. Questo tipo di evento è comune nei servizi a valore aggiunto e a tempo limitato. Analogamente, la risposta 410 viene utilizzata per notificare ai client che una risorsa originariamente appartenente a un individuo sul sito del server corrente non è più disponibile. Naturalmente, spetta al proprietario del server decidere se tutte le risorse permanentemente non disponibili debbano essere contrassegnate come "410 Gone" e per quanto tempo tale contrassegno debba essere mantenuto. |
| 411 | Il server rifiuta di accettare richieste senza l'intestazione Content-Length definita. Dopo aver aggiunto un'intestazione Content-Length valida che indichi la lunghezza del corpo del messaggio di richiesta, il client può inviare nuovamente la richiesta. |
| 412 | Il server non ha soddisfatto uno o più prerequisiti quando ha verificato che fossero indicati nel campo dell'intestazione della richiesta. Questo codice di stato consente al client di impostare i prerequisiti nel metamessaggio della richiesta (dati del campo di intestazione della richiesta) quando ottiene una risorsa, impedendo così che il metodo di richiesta venga applicato a risorse diverse dal contenuto desiderato. |
| 413 | Il server rifiuta di elaborare la richiesta corrente perché presenta dati di entità di dimensioni superiori a quelle che il server è disposto o in grado di gestire. In questo caso, il server può chiudere la connessione per impedire al client di continuare a inviare la richiesta. Se questa condizione è temporanea, il server deve restituire un'intestazione di risposta Retry-After per informare il client di quanto tempo può riprovare dopo. |
| 414 | La lunghezza dell'URI della richiesta supera la lunghezza che il server può interpretare, quindi il server rifiuta di servire la richiesta. Si tratta di un caso raro, che si verifica spesso quando l'invio di un modulo che avrebbe dovuto utilizzare il metodo POST diventa un metodo GET, con il risultato di una Query String lunga. I "buchi neri" degli URI di reindirizzamento, come l'utilizzo del vecchio URI come parte del nuovo URI a ogni reindirizzamento, con il risultato di un URI lungo dopo diversi reindirizzamenti. I client tentano di attaccare i server sfruttando le vulnerabilità di sicurezza presenti in alcuni server. Tali server utilizzano un buffer di lunghezza fissa per leggere o manipolare l'URI di una richiesta e, quando i parametri dopo un GET superano un certo valore, può verificarsi un buffer overflow che porta all'esecuzione di codice arbitrario [1]. I server che non presentano tali vulnerabilità dovrebbero restituire un codice di stato 414. |
| 415 | Per il metodo e la risorsa attualmente richiesti, l'entità presentata nella richiesta non è in un formato supportato dal server, quindi la richiesta viene rifiutata. |
| 416 | Se la richiesta contiene un'intestazione di richiesta Range e qualsiasi intervallo di dati specificato in Range non si sovrappone agli intervalli disponibili per la risorsa corrente, e l'intestazione di richiesta If-Range non è definita nella richiesta, il server dovrebbe restituire un codice di stato 416. Se l'intervallo utilizza intervalli di byte, il caso si verifica se la prima posizione di byte di tutti gli intervalli di dati specificati nella richiesta supera la lunghezza della risorsa corrente. Il server deve anche includere un'intestazione di entità Content-Range che specifichi la lunghezza della risorsa corrente insieme al codice di stato 416. A questa risposta è inoltre vietato utilizzare multipart/byteranges come Content-Type. |
| 417 | Il contenuto atteso specificato nell'intestazione della richiesta Expect non può essere soddisfatto dal server, oppure questo server è un server proxy che ha prove evidenti che il contenuto di Expect non può essere soddisfatto dal nodo successivo nel percorso corrente. |
| 421 | Il numero di connessioni al server dall'indirizzo IP in cui si trova il client corrente supera il massimo consentito dal server. In genere, l'indirizzo IP si riferisce all'indirizzo del client visto dal server (ad esempio, l'indirizzo del gateway o del server proxy dell'utente). In questo caso, il conteggio delle connessioni può riguardare più di un utente finale. |
| 422 | Il numero di connessioni al server dall'indirizzo IP del client corrente supera il massimo consentito dal server. In genere, l'indirizzo IP si riferisce all'indirizzo del client visto dal server (ad esempio, l'indirizzo del gateway o del server proxy dell'utente). In questo caso, il conteggio delle connessioni può coinvolgere più di un utente finale. |
| 422 | La richiesta è stata formattata correttamente, ma non è stato possibile rispondere perché conteneva errori semantici. (RFC 4918 WebDAV) 423 Bloccato La risorsa corrente è bloccata. (RFC 4918 WebDAV) |
| 424 | La richiesta corrente è fallita a causa di un errore verificatosi in una richiesta precedente, ad esempio PROPPATCH.(RFC 4918 WebDAV) |
| 425 | Definito nella bozza WebDav Advanced Collections, ma non compare nel protocollo WebDAV Sequential Collections (RFC 3658). |
| 426 | I client dovrebbero passare a TLS/1.0.(RFC 2817) |
| 449 | Esteso da Microsoft per indicare che le richieste devono essere ritentate dopo che è stata eseguita l'azione appropriata. |
| 500 | Il server ha riscontrato una condizione imprevista che gli ha impedito di completare l'elaborazione della richiesta. In genere, questo problema si verifica quando si verifica un errore nel codice del programma del server. |
| 501 | Il server non supporta una particolare funzione necessaria per la richiesta corrente. Quando il server non è in grado di riconoscere il metodo richiesto e non è in grado di supportare la richiesta di una qualsiasi risorsa. |
| 502 | Un server che lavora come gateway o proxy riceve una risposta non valida da un server a monte quando tenta di eseguire una richiesta. |
| 503 | Il server non è attualmente in grado di elaborare la richiesta a causa di una manutenzione temporanea del server o di un sovraccarico. Questa condizione è temporanea e verrà ripristinata dopo qualche tempo. Se si prevede un ritardo, la risposta può includere un'intestazione Retry-After per indicare il ritardo. Se questa informazione Retry-After non viene fornita, il client deve gestirla allo stesso modo di una risposta 500. Nota: L'esistenza del codice di stato 503 non significa che il server debba utilizzarlo se è sovraccarico. Alcuni server desiderano semplicemente negare la connessione al client. |
| 504 | Un server che lavora come gateway o proxy e che tenta di eseguire una richiesta non riceve una risposta tempestiva da un server upstream (un server identificato da un URI, come HTTP, FTP, LDAP) o da un server secondario (come DNS). Nota: alcuni server proxy restituiscono un errore 400 o 500 quando la ricerca DNS va in tilt. |
| 505 | Il server non supporta o rifiuta di supportare la versione di HTTP utilizzata nella richiesta. Ciò implica che il server non può o non vuole utilizzare la stessa versione del client. La risposta deve contenere un'entità che descrive il motivo per cui la versione non è supportata e quali protocolli supporta il server. |
| 506 | Esteso dal Transparent Content Negotiation Protocol (RFC 2295) per rappresentare una configurazione interna errata da parte del server: la risorsa Negotiation Variant richiesta è configurata per utilizzare se stessa nella negoziazione trasparente dei contenuti e quindi non è un punto di riferimento appropriato in un processo di negoziazione. |
| 507 | Il server non è in grado di memorizzare il contenuto necessario per soddisfare la richiesta. Questa condizione è considerata temporanea.WebDAV (RFC 4918) |
| 509 | Il server ha raggiunto il suo limite di larghezza di banda. Questo non è un codice di stato ufficiale, ma è comunque ampiamente utilizzato. |
| 510 | La politica richiesta per ottenere la risorsa non è stata soddisfatta. (RFC 2774) |