| Codice di stato HTTP | Significato del codice di stato |
|---|
| 100 | Il lato client deve continuare a inviare richieste. Questa risposta temporanea viene utilizzata per informare il lato client che alcune delle sue richieste sono state ricevute dal server e non sono state rifiutate. Il lato client deve continuare a inviare il resto della richiesta o ignorare la risposta se la richiesta è stata completata. Il server deve inviare una risposta finale al lato client dopo che la richiesta è stata completata. |
| 101 | Il server ha compreso la richiesta del client e informerà il lato client tramite l'intestazione Upgrade per utilizzare un protocollo diverso per completare la richiesta. Dopo aver inviato l'ultima riga vuota nella risposta, il server passerà a quei protocolli definiti nell'intestazione Upgrade. Misure simili dovrebbero essere prese solo quando il passaggio a un nuovo protocollo è più vantaggioso. Ad esempio, passare a una nuova versione di HTTP ha vantaggi rispetto a una versione vecchia, o passare a un reale}}-tempo e protocollo sincrono per consegnare risorse che sfruttano tali funzionalità. |
| 102 | Lo stato di codice esteso da WebDAV (RFC 2518) indica che il processo continuerà. |
| 200. | La richiesta è stata eseguita con successo, e gli intestazioni di risposta desiderate o i corpi dei dati sono restituiti con la risposta. |
| 201 | La richiesta è stata soddisfatta, e una nuova risorsa è stata creata in base alle richieste della richiesta, e il suo URI è stato restituito con l'intestazione Location. Se la risorsa richiesta non può essere creata in tempo,'202 Accettato' dovrebbe essere restituito. |
| 202 | Il server ha accettato la richiesta, ma non l'ha ancora elaborata. Proprio come potrebbe essere rifiutata, la richiesta potrebbe o meno essere eseguita alla fine. Nel caso delle operazioni asincrone, non c'è modo più conveniente di fare questo che inviare questo codice di stato. Lo scopo di restituire un 202 risposta di stato del codice per permettere al server di accettare richieste da altri processi (come un batch-operazione basata su segmenti che viene eseguita solo una volta al giorno) senza dover mantenere la connessione del client con il server fino a che l'operazione batch è completa. In risposta all'accettazione di una richiesta di elaborazione e al restituzione di una 202 codice di stato, l'entità restituita dovrebbe includere alcune informazioni che indicano lo stato attuale del processo, nonché un puntatore al monitoraggio o alla previsione dello stato del processo, in modo che l'utente possa stimare se l'operazione è stata completata. |
| 203 | Il server ha elaborato con successo la richiesta, ma le informazioni meta dell'intestazione dell'entità restituita non è un set deterministico valido sul server di origine, ma è locale o di terza-partenza copia. Le informazioni correnti possono essere un sottoinsieme o un superinsieme della versione originale. Ad esempio, i metadati che contengono risorse possono far sapere al server di origine il meta super. L'uso di questo codice di stato non è richiesto e è appropriato solo se la risposta restituisce 200 OK senza questo codice di stato. |
| 204 | Il server ha elaborato con successo la richiesta, ma non è necessario restituire alcun contenuto fisico, e desidera restituire informazioni meta aggiornate. La risposta può essere sotto forma di un'intestazione dell'entità, restituendo nuove o aggiornate informazioni meta. Se questa informazione dell'intestazione esiste, dovrebbe corrispondere alla variabile richiesta. Se il lato client è un browser, allora il browser dell'utente dovrebbe mantenere la pagina che ha inviato la richiesta senza alcuna modifica alla vista del documento, anche se le nuove o aggiornate informazioni meta dovrebbero essere applicate al documento nella vista attiva del browser dell'utente secondo la specifica. Dal momento che 204 risposta è proibita dall'includere qualsiasi corpo del messaggio, termina sempre con la prima riga vuota dopo l'intestazione. |
| 205 | Il server ha elaborato con successo la richiesta e non ha restituito nulla. Ma a differenza del 204 La risposta, la risposta che restituisce questo codice di stato, richiede che il richiedente ripristini la vista del documento. Questa risposta viene principalmente utilizzata per ripristinare il modulo immediatamente dopo l'accettazione dell'input dell'utente in modo che l'utente possa iniziare facilmente un altro input. Come il 204 risposta, questa risposta è anche proibita dall'includere qualsiasi corpo di messaggio e termina con la prima riga vuota dopo l'intestazione. |
| 206 | Il server ha elaborato con successo parte della richiesta GET. Gli strumenti di download HTTP come FlashGet o Xunlei utilizzano questo tipo di risposta per implementare una continuità a punto di interruzione o per spezzare un documento grande in più segmenti di download per il download simultaneo. La richiesta deve contenere un'intestazione Range per indicare l'intervallo di contenuto che il client vuole, e può includere If-Range come condizione di richiesta. La risposta deve contenere gli intestazioni di campo seguenti: Content-Range per indicare l'intervallo di contenuto restituito in questa risposta; se è un multi-scarica segmento con Content-Type multipart/byteranges, ogni segmento multipart deve contenere un Content-l'intestazione Range per indicare l'intervallo di contenuto di questo segmento. Se la risposta contiene Content-Lunghezza, allora il suo valore deve corrispondere al numero effettivo di byte nel intervallo di contenuto che restituisce. Data ETag e/o Content-Location, se la stessa richiesta avrebbe dovuto restituire una 2risposta 00. Expires, Cache-Control, e/o Vary, se il suo valore potrebbe essere diverso dal valore corrispondente a altre risposte alla stessa variabile prima. Se questa risposta di richiesta utilizza If-validazione forte del cache Range, allora questa risposta non dovrebbe includere altri intestazioni di entità; se questa risposta di richiesta utilizza If-validazione debole del cache Range, allora questa risposta non dovrebbe includere altri intestazioni di entità; questo evita incoerenze tra il contenuto dell'entità cache e le informazioni di intestazione dell'entità aggiornate. Altrimenti, questa risposta dovrebbe contenere tutti gli intestazioni di campo dell'entità che dovrebbero essere restituiti in una 2risposta 00. Se l'ETag o l'Ultimo-Modificato non corrispondono esattamente, la cache sul lato client dovrebbe vietare la combinazione del contenuto restituito nella 206 risposta con qualsiasi contenuto precedentemente cache. Qualsiasi cache che non supporta Range e gli intestazioni-L'intestazione Range è proibita dal caching del contenuto restituito dalla 206 risposta. |
| 207 | Un codice di stato esteso da WebDAV (RFC 2518) rappresenta che il corpo del messaggio successivo sarà un messaggio XML e può contenere una serie di codici di risposta indipendenti in base al numero di sottorequisizioni precedenti-. |
| 300 | La risorsa richiesta ha una gamma di opzioni di feedback, ognuna con il proprio indirizzo specifico e richieste del browser-informazioni. L'utente o il browser può scegliere un indirizzo preferito per la reindirizzamento. A meno che non sia una richiesta HEAD, la risposta dovrebbe includere un'entità con una lista di attributi delle risorse e indirizzi dai quali l'utente o il browser può scegliere l'indirizzo di reindirizzamento più appropriato. Il formato di questa entità è determinato dal formato definito da Content-Tipo. Il browser può automaticamente fare la scelta più appropriata in base al formato della risposta e alle proprie capacità. Naturalmente, la negoziazione guidata dall'RFC 2616 non specifica come dovrebbe essere eseguita tale selezione automatica. Se il server stesso ha già una selezione di feedback preferita, l'URI del feedback dovrebbe essere specificato nel campo Location; i browser possono utilizzare questo valore di Location come indirizzo per la reindirizzamento automatico. Inoltre, a meno che non venga specificato diversamente, la risposta è anche cacheabile. |
| 301 | La risorsa richiesta è stata permanentemente spostata in una nuova posizione e qualsiasi riferimento futuro a questa risorsa dovrebbe utilizzare uno dei vari URI restituiti da questa risposta. Se possibile, il lato client con capacità di editing dei link dovrebbe cambiare automaticamente l'indirizzo richiesto in quello restituito dal server. A meno che non venga specificato diversamente, questa risposta è anche cacheabile. Il nuovo URI permanente dovrebbe essere restituito nel campo Location della risposta. A meno che non sia una richiesta HEAD, l'entità di risposta dovrebbe contenere un hyperlink all'URI nuovo e una breve descrizione. Se non è una richiesta GET o HEAD, il browser è proibito da automaticamente reindirizzare a meno che non sia confermato dall'utente, poiché le condizioni della richiesta potrebbero cambiare di conseguenza. Nota: Per alcuni browser che utilizzano la specifica HTTP/1.0 protocollo, quando inviano una richiesta POST e ricevono un 301 richiesta, la successiva richiesta di reindirizzamento sarà GET. |
| 302 | La risorsa richiesta risponde temporaneamente alla richiesta da un'altra URI. Poiché tali reindirizzamenti sono temporanei, il lato client dovrebbe continuare a inviare future richieste all'indirizzo originale. Questa risposta è cacheabile solo se specificato in Cache-Control o Expires. La nuova URI temporanea dovrebbe essere restituita nel campo Location della risposta. A meno che non sia una richiesta HEAD, l'entità della risposta dovrebbe contenere un hyperlink all'URI nuovo e una breve descrizione. Se non è una richiesta GET o HEAD, il browser proibisce la reindirizzamento automatico a meno che non sia confermato dall'utente, poiché le condizioni della richiesta possono cambiare di conseguenza. Nota: Anche se l'RFC 1945 e RFC 2068 specifiche non permettono al lato client di cambiare il metodo della richiesta quando si reindirizza, molti browser esistenti trattano i 302 risposta come 303 risposta e utilizzare GET per accedere all'URI specificato nel campo Location, ignorando il metodo della richiesta originale. Codici di stato 303 e 307 sono stati aggiunti per chiarire cosa il server si aspetta dal lato client. |
| 303 | La risposta alla richiesta corrente può essere trovata su un'altra URI e il lato client dovrebbe avere accesso GET a quella risorsa. Questo metodo esiste principalmente per permettere allo script-l'output della richiesta POST attivato per essere reindirizzato a una nuova risorsa. Questa nuova URI non è una referenza sostitutiva della risorsa originale. Anche 303 le risposte sono proibite dall'essere cacheate. Naturalmente, una seconda richiesta (redirection) può essere cacheata. Il nuovo URI dovrebbe essere restituito nel campo Location della risposta. A meno che non sia una richiesta HEAD, l'entità di risposta dovrebbe contenere un hyperlink all'URI nuovo e una breve descrizione. Nota: Molti browser prima di HTTP/1.1 non comprendono 303 lo stato correttamente. Se è necessario considerare l'interazione con questi browser, il 302 il codice di stato dovrebbe essere sufficiente, perché la maggior parte dei browser gestisce 302 le risposte esattamente nello stesso modo in cui la specifica sopra richiede che il lato client le gestisca 303 risposte. |
| 304 | Se il lato client invia una richiesta GET condizionale e la richiesta è stata permessa, e il contenuto del documento non è cambiato (dalultimo accesso o secondo le condizioni della richiesta), il server dovrebbe restituire questo codice di stato. 304 le risposte sono proibite dall'includere messaggi di corpo, quindi devono sempre finire con la prima riga vuota dopo l'intestazione. La risposta deve contenere le seguenti informazioni di header: Date, a meno che questo server non abbia un orologio.
Se anche il server senza orologio segue queste regole, allora il server proxy e il lato client possono aggiungere il campo Date all'intestazione di risposta ricevuta da soli (come specificato in RFC 2068), e il meccanismo di caching funzionerà bene. ETag e/o Content-Location, se la stessa richiesta avrebbe dovuto restituire una 2risposta 00. Expires, Cache-Control, e/o Vary, se il suo valore potrebbe essere diverso dal valore corrispondente alle altre risposte alla stessa variabile prima.
Se questa richiesta di risposta utilizza una validazione di cache forte, allora questa risposta non dovrebbe includere altri header di entità; altrimenti (ad esempio, una richiesta GET condizionale utilizza una validazione di cache debole), questa risposta è proibita dall'includere altri header di entità; questo evita le incoerenze tra il contenuto dell'entità in cache e le informazioni di header dell'entità aggiornate. Se un 304 risposta indica che un'entità non è attualmente nel cache, il sistema di caching deve ignorare la risposta e inviare richieste ripetute senza restrizioni.
Se una 304 risposta ricevuta per aggiornare una voce nel cache, il sistema di caching deve aggiornare l'intera voce per riflettere i valori di tutti i campi che sono stati aggiornati nella risposta. |
| 305 | La risorsa richiesta deve essere acceduta tramite il proxy specificato. Le informazioni dell'URI del proxy specificato sono date nel campo Location. Il ricevente deve inviare una richiesta separata più volte per accedere alla risorsa corrispondente attraverso questo proxy. Solo il server di origine può stabilire un 305 risposta. Nota: Non esiste un chiaro 305 risposta nel RFC 2068 per redirezionare una singola richiesta e può essere stabilita solo dal server di origine. Ignorare queste restrizioni può portare a conseguenze di sicurezza serie. |
| 306 | Nella versione più recente della specifica, la 306 il codice di stato non è più utilizzato. |
| 307 | La risorsa richiesta risponde temporaneamente alla richiesta da un URI diverso. Poiché tali redirezioni sono temporanee, il lato client deve continuare a inviare future richieste all'indirizzo originale. Questa risposta è memorizzabile nel cache solo se specificato in Cache-Controllo o Scadenza. Il nuovo URI temporaneo deve essere restituito nel campo Location della risposta. A meno che non sia una richiesta HEAD, l'entità rispondente deve contenere un hyperlink che punta al nuovo URI e una breve descrizione. Poiché alcuni browser non riconoscono la 307 risposta, l'informazione sopra riportata deve essere aggiunta in modo che l'utente possa comprendere e richiedere l'accesso al nuovo URI.
Se questa non è una richiesta GET o HEAD, il browser proibisce la redirezione automatica se non confermata dall'utente, poiché le condizioni della richiesta possono cambiare di conseguenza. |
| 400 | 1. I semantiche sono errati e la richiesta corrente non può essere compresa dal server. A meno che non venga modificato, il lato client non dovrebbe presentare la richiesta ripetutamente. 2. I parametri della richiesta sono errati. |
| 401 | La richiesta corrente richiede autenticazione dell'utente. La risposta deve contenere un WWW-header di autenticazione per la risorsa richiesta per chiedere all'utente informazioni. Il lato client può risubmettere una richiesta con le informazioni appropriate dell'header di Autorizzazione. Se la richiesta corrente già contiene certificati di Autorizzazione, allora il 401 risposta rappresenta che il server ha rifiutato quei certificati. Se il 401 risposta contiene la stessa query di autenticazione della risposta precedente e il browser ha tentato l'autenticazione almeno una volta, allora il browser dovrebbe mostrare all'utente le informazioni sull'entità contenute nella risposta, poiché queste informazioni sull'entità possono contenere informazioni diagnostiche rilevanti. Vedi RFC 2617. |
| 402 | Questo codice di stato è riservato per possibili esigenze future. |
| 403 | Il server ha compreso la richiesta, ma ha rifiutato di eseguirla. Contrariamente a una 401 risposta, l'autenticazione non aiuta e la richiesta non dovrebbe essere ripetuta. Se questa non è una richiesta HEAD e il server desidera essere in grado di spiegare perché la richiesta non può essere eseguita, allora il motivo del rifiuto dovrebbe essere descritto all'interno dell'entità. Naturalmente, il server può anche restituire un 404 risposta se non desidera che il lato client riceva alcuna informazione. |
| 404 | La richiesta è fallita e la risorsa desiderata non è stata trovata sul server. Non ci sono informazioni per informare l'utente se la condizione è temporanea o permanente. Se il server è a conoscenza della situazione, the 410 Il codice di stato dovrebbe essere utilizzato per informare la risorsa vecchia che è permanentemente non disponibile a causa di un meccanismo di configurazione interna e non ha alcun indirizzo a cui saltare. The 404 Il codice di stato è ampiamente utilizzato quando il server non desidera rivelare il motivo per cui la richiesta è stata rifiutata o non è disponibile alcun'altra risposta adeguata. |
| 405 | Il metodo di richiesta specificato nella riga della richiesta non può essere utilizzato per richiedere la risorsa corrispondente. La risposta deve restituire un header Allow indicando una lista dei metodi di richiesta che possono essere accettati dalla risorsa corrente. Poiché i metodi PUT e DELETE scrivono risorse sul server, molti server web non supportano o non permettono di default il metodo di richiesta sopra elencato e restituiranno un 405 errore per tali richieste. |
| 406 | Le caratteristiche del contenuto della risorsa richiesta non soddisfano le condizioni nell'intestazione della richiesta, quindi non può essere generata una entità di risposta. A meno che questa non sia una richiesta HEAD, la risposta dovrebbe restituire un'entità che permetta all'utente o al browser di selezionare le caratteristiche dell'entità più appropriate e l'elenco degli indirizzi. Il formato dell'entità è determinato dal tipo di media definito nel Content-Header di tipo. Il browser può fare la migliore scelta in base al formato e alle proprie capacità. Tuttavia, la specifica non definisce alcun criterio per fare tali selezioni automatiche. |
| 407 | Simile a 401 , eccetto che il lato client deve autenticarsi sul server proxy. Il server proxy deve restituire una rispostaProxy-Autenticarsi per l'autenticazione. Il lato client può restituire una rispostaProxy-Header di autorizzazione per l'autenticazione. Vedi RFC 2617. |
| 408 | Tempo di richiesta scaduto. Il lato client non ha completato l'invio della richiesta entro il tempo in cui il server era pronto ad aspettare. Il lato client può risubmettere la richiesta in qualsiasi momento senza modifiche. |
| 409 | La richiesta non può essere completata a causa di un conflitto con lo stato attuale della risorsa richiesta. Questo codice è consentito solo se si assume che l'utente sia in grado di risolvere il conflitto e risubmettere una nuova richiesta. La risposta dovrebbe contenere abbastanza informazioni per l'utente per scoprire la fonte del conflitto. I conflitti si verificano solitamente durante il processo delle richieste PUT. Ad esempio, in una versione-ambiente verificato, se le informazioni di versione attaccate a un PUT-richiesta di modifica presentata per una risorsa particolare conflitta con una precedente (terza-parte) richiesta, il server dovrebbe restituire un 409 errore che informa l'utente che la richiesta non potrebbe essere completata.
A questo punto, l'entità di risposta è probabilmente contenente una comparazione delle differenze tra le due versioni in conflitto, in modo che l'utente possa rinviare la versione combinata. |
| 410 | La risorsa richiesta non è più disponibile sul server e non ha alcun indirizzo di reindirizzamento noto. Questa condizione dovrebbe essere considerata permanente. Se possibile, il lato client con capacità di editing dei link dovrebbe rimuovere tutte le referenze a questo indirizzo con il permesso dell'utente. Se il server non conosce o non può determinare se questa condizione è permanente, allora un 404 dovrebbe essere utilizzato il codice di stato. A meno che non venga specificato diversamente, questa risposta è cacheabile. Lo scopo del 410 La risposta è principalmente per aiutare l'amministratore del sito web a mantenere il sito, informare l'utente che la risorsa non è più disponibile e che il proprietario del server desidera che tutte le connessioni remote a questa risorsa vengano eliminate.
Questo tipo di evento è comune nel tempo-valore limitato-servizi aggiunti. Allo stesso modo, il 410 La risposta è utilizzata per informare il lato client che le risorse originariamente appartenenti a un individuo non sono più disponibili sul sito del server attuale. Naturalmente, spetta interamente al proprietario del server decidere se contrassegnare tutte le risorse permanentemente non disponibili come' 410 Andato ', e per quanto tempo mantenere questo marchio. |
| 411 | Il server rifiuta di accettare la richiesta senza definire un contenuto-Intestazione di lunghezza. Dopo aver aggiunto un contenuto valido-Intestazione di lunghezza che indica la lunghezza del corpo della richiesta, il lato client può inviare di nuovo la richiesta. |
| 412 | Il server non è riuscito a soddisfare uno o più dei prerequisiti quando ha verificato che fossero forniti nel campo dell'intestazione della richiesta. Questo codice di stato permette al lato client di impostare i prerequisiti nei metadati richiesti (dati del campo dell'intestazione della richiesta) quando recupera risorse, prevenendo che il metodo di richiesta venga applicato a risorse diverse da quelle desiderate. |
| 413 | Il server rifiuta di elaborare la richiesta corrente perché la richiesta invia più dati dell'entità rispetto a quelli che il server è disposto o in grado di gestire. In questo caso, il server può chiudere la connessione per prevenire che il lato client continui a inviare la richiesta. Se questa situazione è temporanea, il server dovrebbe restituire un Retry-Dopo l'intestazione di risposta per informare il lato client di quanto tempo può cercare di nuovo. |
| 414 | L'URI richiesto è più lungo di quanto il server possa interpretare, quindi il server rifiuta di servire la richiesta. Questo è raro e casi comuni includono: Un invio di modulo che dovrebbe aver utilizzato il metodo POST diventa un metodo GET, causando la lunghezza della stringa di ricerca (Query String) eccessiva. URI di reindirizzamento "buchi neri", come ogni reindirizzamento che utilizza l'URI vecchio come parte dell'URI nuovo, risultando in un URI troppo lungo dopo diversi reindirizzamenti. Il client sta cercando di attaccare il server con bug di sicurezza che esistono in alcuni server.
Questo tipo di server utilizza un-buffer di lunghezza per leggere o manipolare l'URI richiesto. Quando i parametri dopo GET superano un determinato valore, può verificarsi un overflow di buffer, risultando nell'esecuzione di codice arbitrario [1]. I server senza tali vulnerabilità dovrebbero restituire un 414 codice di stato. |
| 415 | Per il metodo della richiesta corrente e la risorsa richiesta, l'entità inviata nella richiesta non è in un formato supportato dal server, quindi la richiesta viene rifiutata. |
| 416 | Se la richiesta contiene un'intestazione di intervallo e qualsiasi intervallo di dati specificato nell'intervallo non coincide con l'intervallo disponibile della risorsa corrente, e l'If-L'intestazione di intervallo non è definita nella richiesta, il server dovrebbe restituire un 416 status code. Se l'Range utilizza un intervallo di byte, allora questa situazione significa che la posizione iniziale del byte di tutti gli intervalli di dati specificati dalla richiesta supera la lunghezza della risorsa corrente. Il server dovrebbe anche includere un Content-l'header dell'entità Range insieme al 416 status code per indicare la lunghezza della risorsa corrente. Questa risposta è anche proibita dall'uso di multipart/byteranges come il suo Contenuto-Tipo. |
| 417 | Il contenuto atteso specificato nell'intestazione di richiesta Expect non può essere soddisfatto dal server, o il server è un server proxy che ha chiaro evidence che il contenuto atteso non può essere soddisfatto nel nodo successivo del percorso corrente. |
| 421 | Il numero di connessioni al server dall'indirizzo di protocollo Internet dove si trova il lato client attuale supera il massimo consentito dal server. Tipicamente, l'indirizzo di protocollo Internet qui si riferisce all'indirizzo del lato client visto dal server (ad esempio, l'indirizzo del gateway o del server proxy dell'utente). In questo caso, il conteggio delle connessioni potrebbe coinvolgere più di un utente finale. |
| 422 | Il numero di connessioni al server dall'indirizzo di protocollo Internet dove si trova il lato client attuale supera il massimo consentito dal server. Tipicamente, l'indirizzo di protocollo Internet qui si riferisce all'indirizzo del lato client visto dal server (ad esempio, l'indirizzo del gateway o del server proxy dell'utente). In questo caso, il conteggio delle connessioni potrebbe coinvolgere più di un utente finale. |
| 422 | La richiesta è stata formattata correttamente, ma non è stato possibile rispondere a causa di un errore semantico. (RFC 4918 WebDAV) 423 Bloccato Il risorsa corrente è bloccata. (RFC 4918 WebDAV) |
| 424 | La richiesta corrente è fallita a causa di un errore in una richiesta precedente, come PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Definito nel draft delle Collectives Avanzate WebDav, ma non nel Protocollo Sequenziale Set WebDAV (RFC 3658). |
| 426 | Il lato client dovrebbe passare a TLS/1.0. (RFC 2817) |
| 449 | Esteso da Microsoft, le richieste devono essere riprovate dopo aver eseguito l'azione appropriata. |
| 500 | Il server ha incontrato una situazione inaspettata che ha impedito di completare la richiesta. Generalmente, questo problema si verifica quando il codice del server fallisce. |
| 501 | Il server non supporta una funzionalità richiesta dalla richiesta corrente. Quando il server non può riconoscere il metodo richiesto e non può supportare la sua richiesta per qualsiasi risorsa. |
| 502 | Quando un server che funziona come gateway o proxy tenta di eseguire una richiesta, riceve una risposta non valida da un server in alto. |
| 503 | Il server non è in grado di elaborare le richieste in questo momento a causa della manutenzione temporanea del server o dell'overload. Questa condizione è temporanea e verrà ripristinata dopo un certo periodo di tempo. Se il tempo di attesa può essere previsto, la risposta può includere un Retry-dopo l'intestazione per indicare il tempo di attesa. Se questo Retry-Dopo che le informazioni non sono state fornite, il lato client dovrebbe trattarle come se fossero un 5risposta 00. Nota: L'esistenza di un 503 codice di stato non significa che il server deve utilizzarlo in caso di sovraccarico. Alcuni server desiderano semplicemente negare la connessione del client. |
| 504 | Quando un server che lavora come gateway o proxy tenta di eseguire una richiesta, non riceve una risposta da un server in alto (identificato dall'URI, come HTTP, FTP, LDAP) o da un server secondario (come DNS) in modo tempestivo. Nota: Alcuni server proxy restituiscono un 400 o 5Errore 00 quando la query DNS scade |
| 505 | Il server non supporta o rifiuta di supportare la versione di HTTP utilizzata nella richiesta. Questo implica che il server non può o non utilizzerà la stessa versione del lato client. La risposta dovrebbe includere un'entità che descriva perché la versione non è supportata e quali protocolli il server supporta. |
| 506 | Esteso dal Protocollo di Negoziazione di Contenuto Trasparente (RFC 2295), questo rappresenta un errore di configurazione interna sul server: la risorsa variabile di negoziazione richiesta è configurata per utilizzare se stessa in una negoziazione di contenuto trasparente e quindi non è un punto appropriato in un processo di negoziazione. |
| 507 | Il server non può archiviare il contenuto necessario per completare la richiesta. Questa condizione è considerata temporanea. WebDAV (RFC 4918) |
| 509 | Il server ha raggiunto il limite di banda. Questo non è un codice di stato ufficiale, ma è ancora ampiamente utilizzato. |
| 510 | Non vengono soddisfatte le politiche necessarie per acquisire risorse. (RFC 2774) |
