| Codice di stato HTTP |
Significato del codice di stato |
| 100 |
Il client dovrebbe continuare a inviare la richiesta. Questa risposta temporanea è utilizzata per notificare al client che parte della sua richiesta è già stata ricevuta dal server e non è stata ancora rifiutata. Il client dovrebbe continuare a inviare il resto della richiesta, oppure se la richiesta è già completata, ignorare questa risposta. Il server deve inviare una risposta finale al client dopo l'esecuzione della richiesta. |
| 101 |
Il server ha già compreso la richiesta del client e notificherà il client tramite l'header Upgrade che utilizzerà un protocollo diverso per completare la richiesta. Dopo aver inviato l'ultima riga vuota della risposta, il server passerà ai protocolli definiti nell'header Upgrade. Questo deve essere fatto solo se il passaggio al nuovo protocollo è più vantaggioso. Ad esempio, passare a una nuova versione di HTTP è più vantaggioso rispetto alla vecchia, oppure passare a un protocollo in tempo reale e sincrono per trasmettere risorse che sfruttano tali caratteristiche. |
| 102 |
Codice di stato esteso da WebDAV (RFC 2518) che indica che l'elaborazione continuerà. |
| 200 |
Richiesta riuscita, gli header di risposta o il corpo dati desiderato saranno restituiti con questa risposta. |
| 201 |
La richiesta è stata implementata e una nuova risorsa è stata creata in base alle esigenze della richiesta e il suo URI è stato restituito con l'header Location. Se la risorsa richiesta non può essere creata in modo tempestivo, deve essere restituito '202 Accepted'. |
| 202 |
Il server ha accettato la richiesta ma non l'ha ancora elaborata. Come potrebbe anche essere rifiutata, la richiesta finale non potrebbe o potrebbe essere eseguita. In caso di operazioni asincrone, non c'è modo migliore di inviare questo codice di stato. La risposta che restituisce lo stato 202 ha lo scopo di consentire al server di accettare richieste per altri processi (ad esempio, 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. Nel restituire 202 come risposta all'elaborazione della richiesta, la risposta deve includere alcune informazioni sull'attuale stato di elaborazione, insieme a un puntatore a monitor di stato o previsione di stato, per consentire all'utente di stimare se l'operazione è stata completata. |
| 203 |
Il server ha elaborato con successo la richiesta, ma le informazioni di intestazione del corpo dell'entità restituita non sono una raccolta definitiva valida sul server originale, ma sono una copia locale o di terze parti. Le informazioni attuali potrebbero essere un sottoinsieme o un superset della versione originale. Ad esempio, i metadati che contengono le risorse potrebbero portare il server originale a conoscere i metadati super. Non è obbligatorio utilizzare questo codice di stato, ed è appropriato solo quando la risposta non restituirebbe 200 OK senza di esso. |
| 204 |
Il server ha elaborato con successo la richiesta, ma non è necessario restituire alcun contenuto dell'entità e desidera restituire informazioni aggiornate. La risposta potrebbe restituire nuove o aggiornate informazioni tramite header dell'entità. Se esistono queste intestazioni, devono corrispondere alle variabili richieste. Se il client è un browser, allora il browser dell'utente deve mantenere la pagina che ha inviato la richiesta senza alcuna modifica nella visualizzazione del documento, anche se secondo la specifica le nuove o aggiornate informazioni devono essere applicate alla vista del browser attiva dell'utente nel documento. Poiché la risposta 204 è vietata dall'includere qualsiasi corpo di messaggio, termina sempre con la prima riga vuota dopo l'header del messaggio. |
| 205 |
Il server ha elaborato correttamente la richiesta e non ha restituito alcun contenuto. Tuttavia, a differenza della risposta 204, la risposta con questo codice di stato richiede al richiedente di ripristinare la visualizzazione del documento. Questa risposta è principalmente utilizzata per ripristinare immediatamente un modulo dopo aver apportato un input utente, in modo che l'utente possa iniziare facilmente un'altra input. Come per la risposta 204, la risposta è anche vietata dall'includere qualsiasi corpo di messaggio e termina con la prima riga vuota dopo l'header del messaggio. |
| 206 |
Il server ha già elaborato con successo parte di una richiesta GET. Strumenti HTTP per il download come FlashGet o Xunlei utilizzano questo tipo di risposta per implementare il ripristino di download o per suddividere un grande documento in più segmenti da scaricare contemporaneamente. La richiesta deve includere l'header Range per indicare l'intervallo di contenuto desiderato dal client e potrebbe includere un If-Range come condizione della richiesta. La risposta deve contenere i seguenti campi di intestazione: Content-Range per indicare l'intervallo di contenuto restituito in questa risposta; se è Content-Type di multi-party byte ranges per download multipli, ognuno dei segmenti multipart deve includere il campo Content-Range per indicare l'intervallo di contenuto di quel segmento. Se nella risposta è presente Content-Length, il suo valore deve corrispondere al numero reale di byte dell'intervallo di contenuto restituito. Date ETag e/o Content-Location, se la stessa richiesta dovrebbe restituire 200 come risposta. Expires, Cache-Control, e/o Vary, se i valori potrebbero differire da quelli delle altre risposte corrispondenti a precedenti variabili dello stesso valore. Se questa risposta di richiesta utilizza la verifica di cache forte If-Range, allora questa risposta non dovrebbe includere altre intestazioni dell'entità; se questa risposta di richiesta utilizza la verifica di cache debole If-Range, allora questa risposta vieta di includere altre intestazioni dell'entità; questo per evitare l'incoerenza tra il contenuto dell'entità detenuta in cache e le intestazioni dell'entità aggiornate. In caso contrario, questa risposta deve includere tutte le intestazioni dell'entità che avrebbero dovuto essere restituite nella risposta 200. Se l'intestazione ETag o Last-Modified non può corrispondere esattamente, la cache del client deve vietare la combinazione del contenuto restituito dalla risposta 206 con qualsiasi contenuto precedentemente memorizzato nella cache. Qualsiasi cache che non supporta l'header Range e Content-Range deve vietare la memorizzazione della risposta 206. |
| 207 |
Codice di stato esteso da WebDAV (RFC 2518), indica che il messaggio successivo sarà un messaggio XML, e potrebbe contenere una serie di codici di risposta indipendenti in base al numero di sottorichieste precedenti. |
| 300 |
Le risorse richieste hanno una serie di informazioni di feedback tra cui scegliere, ognuna con il proprio indirizzo specifico e le informazioni commerciali guidate dal browser. L'utente o il browser può scegliere un indirizzo preferito per fare il reindirizzamento. A meno che non sia una richiesta HEAD, la risposta dovrebbe includere un'entità che elenca le caratteristiche e gli indirizzi delle risorse, affinché l'utente o il browser possano scegliere il reindirizzamento più appropriato. Il formato di questa entità è determinato dal formato definito nell'header Content-Type. I browser possono fare automaticamente la scelta più appropriata in base al formato della risposta e alla propria capacità. Naturalmente, la specifica RFC 2616 non stabilisce come tale selezione automatica dovrebbe avvenire. Se il server ha già una scelta di feedback preferita, l'URI di questo feedback deve essere specificato in Location; il browser potrebbe utilizzare questo valore di Location come indirizzo di reindirizzamento automatico. Inoltre, a meno di una specifica aggiuntiva, questa risposta è anche cacheabile. |
| 301 |
La risorsa richiesta è stata spostata permanentemente in una nuova posizione, e tutte le future referenze a questa risorsa dovrebbero utilizzare uno degli URI restituiti da questa risposta. Se possibile, i client con funzioni di modifica dei collegamenti dovrebbero automaticamente modificare l'indirizzo richiesto in quello restituito dal server. A meno di una specifica aggiuntiva, 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à della risposta dovrebbe includere un collegamento ipertestuale all'URI nuovo e una breve descrizione. Se questa non è una richiesta GET o HEAD, il browser vieta il reindirizzamento automatico, a meno che non riceva la conferma dell'utente, poiché le condizioni della richiesta potrebbero cambiare a causa di ciò. Nota: per alcuni browser che utilizzano il protocollo HTTP/1.0, quando inviano una richiesta POST e ottengono una risposta 301, la richiesta di reindirizzamento successivo diventerà un metodo GET. |
| 302 |
La risorsa richiesta ora risponde temporaneamente a una richiesta da un URI diverso. Poiché questo reindirizzamento è temporaneo, il client dovrebbe continuare a inviare richieste all'indirizzo originale. Questa risposta è cacheabile solo se specificato in Cache-Control o Expires. Il nuovo URI temporaneo dovrebbe essere restituito nel campo Location della risposta. A meno che non sia una richiesta HEAD, l'entità della risposta dovrebbe contenere un collegamento ipertestuale all'URI nuovo e una breve descrizione. Se questa non è una richiesta GET o HEAD, il browser vieta il reindirizzamento automatico, a meno che non riceva conferma dall'utente, poiché le condizioni della richiesta potrebbero cambiare a causa di ciò. Nota: sebbene le specifiche RFC 1945 e RFC 2068 non consentano ai client di cambiare il metodo della richiesta durante il reindirizzamento, molti browser esistenti interpretano una risposta 302 come se fosse 303 e accedono all'URI specificato in Location utilizzando il metodo GET, ignorando il metodo della richiesta originale. I codici di stato 303 e 307 sono stati aggiunti per specificare esplicitamente quale reazione è attesa dal client. |
| 303 |
La risposta alla richiesta corrente può essere trovata in un altro URI, e il client dovrebbe accedere a quella risorsa utilizzando il metodo GET. Questo metodo esiste principalmente per consentire al risultato di una richiesta POST attivata da uno script di essere reindirizzato a una nuova risorsa. Questo nuovo URI non è un riferimento sostitutivo della risorsa originale. Inoltre, la risposta 303 non è cacheabile; naturalmente, la seconda richiesta (reindirizzamento) potrebbe essere cacheabile. Il nuovo URI dovrebbe essere restituito nel campo Location della risposta. A meno che non sia una richiesta HEAD, l'entità della risposta dovrebbe includere un collegamento ipertestuale all'URI nuovo e una breve descrizione. Nota: molti browser precedenti alla versione HTTP/1.1 non comprendono correttamente lo stato 303. Se è necessario considerare l'interazione con questi browser, il codice di stato 302 dovrebbe sufficiente, poiché il modo in cui la maggior parte dei browser gestisce le risposte 302 è esattamente ciò che la specifica richiede che il client faccia con la risposta 303. |
| 304 |
Se un client ha inviato una richiesta GET condizionata e quella richiesta è stata accettata, e il contenuto del documento (dalla ultima visita o secondo le condizioni della richiesta) non è cambiato, il server dovrebbe restituire questo codice di stato. La risposta 304 è vietata dall'includere un corpo del messaggio, quindi termina sempre con la prima riga vuota dopo l'header del messaggio. La risposta deve includere le seguenti intestazioni: Date, a meno che il server non abbia un orologio. Se il server senza orologio aderisce a queste regole, il server proxy e il client possono generare autonomamente il campo Data da aggiungere all'header della risposta ricevuta (come stabilito nella RFC 2068), e il meccanismo di cache funzionerà normalmente. ETag e/o Content-Location, se la stessa richiesta avrebbe dovuto restituire una risposta 200. Expires, Cache-Control, e/o Vary, se i valori potrebbero differire da quelli delle altre risposte corrispondenti a precedenti variabili dello stesso valore. Se questa risposta di richiesta utilizza la verifica di cache forte, questa risposta non dovrebbe includere altre intestazioni dell'entità; altrimenti (ad esempio, se una richiesta GET condizionata utilizza la verifica di cache debole), questa risposta vieta di includere altre intestazioni dell'entità; ciò evita l'incoerenza tra il contenuto dell'entità detenuta in cache e le intestazioni dell'entità aggiornate. Se una risposta 304 indica che un'entità corrente non ha una cache, il sistema di cache deve ignorare questa risposta e ripetere l'invio di una richiesta senza condizioni. Se si riceve una risposta 304 che richiede l'aggiornamento di un elemento nella cache, il sistema di cache deve aggiornare l'intero elemento per riflettere tutti i valori dei campi aggiornati nella risposta. |
| 305 |
La risorsa richiesta deve essere accessibile tramite il proxy specificato. Il campo Location fornirà l'URI del proxy specificato, e il destinatario deve inviare nuovamente una richiesta separata per accedere alla risorsa. Solo il server originale può generare una risposta 305. Nota: La RFC 2068 non specifica chiaramente che la risposta 305 è per reindirizzare una singola richiesta e può essere generata solo dal server originale. Ignorare questi limiti può comportare gravi conseguenze per la sicurezza. |
| 306 |
Nel più recente standard, il codice di stato 306 non è più in uso. |
| 307 |
La risorsa richiesta risponde ora temporaneamente a una richiesta da un URI diverso. Poiché questo reindirizzamento è temporaneo, il client dovrebbe continuare a inviare richieste all'indirizzo originale. Questa risposta è cacheabile solo se specificato in Cache-Control o Expires. Il nuovo URI temporaneo dovrebbe essere restituito nel campo Location della risposta. A meno che non sia una richiesta HEAD, l'entità della risposta dovrebbe contenere un collegamento ipertestuale all'URI nuovo e una breve descrizione. Poiché alcuni browser potrebbero non riconoscere la risposta 307, è necessario fornire le informazioni necessarie affinché l'utente possa comprendere e richiedere l'accesso al nuovo URI. Se questa non è una richiesta GET o HEAD, il browser vieta il reindirizzamento automatico, a meno di conferma dell'utente, poiché le condizioni della richiesta potrebbero cambiare. |
| 400 |
1. La semantica è errata e la richiesta corrente non può essere compresa dal server. A meno che non siano state apportate modifiche, il client non dovrebbe ripetere questa richiesta. 2. I parametri della richiesta sono errati. |
| 401 |
La richiesta corrente richiede l'autenticazione dell'utente. Questa risposta deve contenere un header WWW-Authenticate appropriato per la risorsa richiesta per interrogare le informazioni dell'utente. Il client può ripetere la richiesta contenente un header Authorization appropriato. Se la richiesta corrente già include un certificato di autorizzazione, la risposta 401 rappresenta un rifiuto da parte del server di confermare quei certificati. Se la risposta 401 include la stessa richiesta di autenticazione della risposta precedente, e il browser ha già tentato almeno una volta l'autenticazione, il browser dovrebbe mostrare all'utente le informazioni contenute nell'entità della risposta, poiché queste informazioni potrebbero contenere informazioni diagnostiche pertinenti. Fare riferimento alla RFC 2617. |
| 402 |
Questo codice di stato è riservato per esigenze future. |
| 403 |
Il server ha compreso la richiesta, ma rifiuta di eseguirla. A differenza della risposta 401, l'autenticazione non è d'aiuto e non dovrebbe essere ripetuta la richiesta. Se questa non è una richiesta HEAD e il server desidera chiarire perché la richiesta non può essere eseguita, dovrebbe descrivere nella sua entità i motivi del rifiuto. Naturalmente, il server può anche restituire una risposta 404, se non desidera che il client ottenga alcuna informazione. |
| 404 |
La richiesta è fallita, la risorsa desiderata non è stata trovata sul server. Non ci sono informazioni per informare l'utente se questo stato è temporaneo o permanente. Se il server è a conoscenza della situazione, dovrebbe utilizzare il codice di stato 410 per informare che la risorsa vecchia non è più disponibile a causa di alcuni problemi interni di configurazione e non ci sono indirizzi ai quali fare riferimento. Il codice di stato 404 è ampiamente utilizzato quando il server non desidera rivelare perché una richiesta è stata rifiutata o non ci sono altre risposte appropriate disponibili. |
| 405 |
Il metodo di richiesta specificato nella riga di richiesta non può essere utilizzato per la risorsa richiesta. Questa risposta deve restituire un header Allow per indicare un elenco dei metodi di richiesta attualmente accettabili per quella risorsa. Poiché i metodi PUT e DELETE eseguono operazioni di scrittura sulle risorse sul server, la maggior parte dei server web non supporta o non consente, nella configurazione predefinita, i metodi di richiesta sopra menzionati, e restituirà un errore 405 per tali richieste. |
| 406 |
Le caratteristiche di contenuto della risorsa richiesta non possono soddisfare le condizioni negli header della richiesta, quindi non può essere generato il corpo della risposta. A meno che non sia una richiesta HEAD, questa risposta dovrebbe restituire un'entità che contenga un elenco di caratteristiche di contenuto che l'utente o il browser può scegliere come più appropriate. Il formato dell'entità è determinato dal tipo di media definito nell'header Content-Type. I browser possono fare la scelta migliore in base al formato e alle proprie capacità. Tuttavia, la specifica non definisce alcuno standard per tali selezioni automatiche. |
| 407 |
Simile alla risposta 401, ma il client deve autenticarsi sul server proxy. Il server proxy deve restituire un Proxy-Authenticate per richiedere l'autenticazione. Il client può restituire un header Proxy-Authorization per l'autenticazione. Fare riferimento alla RFC 2617. |
| 408 |
Timeout della richiesta. Il client non ha completato l'invio di una richiesta all'interno del tempo che il server era disposto a attendere. Il client può inviare nuovamente tale richiesta in qualsiasi momento senza apportare modifiche. |
| 409 |
La richiesta non può essere completata a causa di un conflitto con lo stato attuale della risorsa richiesta. Questo codice è consentito solo in circostanze in cui l'utente è considerato in grado di risolvere il conflitto e rinviare una nuova richiesta. La risposta deve contenere informazioni sufficienti per far scoprire all'utente la fonte del conflitto. I conflitti si verificano comunemente durante il processamento di una richiesta PUT. Ad esempio, in un ambiente che utilizza il controllo delle versioni, se una richiesta di modifica inviata con PUT ha informazioni di versione che confliggono con una precedente richiesta (di terzi), il server dovrebbe restituire un errore 409 per segnalare che la richiesta non può essere completata. In questa risposta, l'entità molto probabilmente conterrà un confronto delle differenze tra le due versioni in conflitto, affinché l'utente possa ripresentare una nuova versione unita. |
| 410 |
La risorsa richiesta non è più disponibile sul server e non ci sono indirizzi di inoltro noti. Questa situazione dovrebbe essere considerata permanente. Se possibile, i client con funzioni di modifica dei collegamenti dovrebbero cancellare tutti i riferimenti a questo indirizzo, dopo aver ottenuto il permesso dell'utente. Se il server non sa o non può determinare se questa situazione sia permanente, allora dovrebbe utilizzare il codice di stato 404. A meno di una specifica aggiuntiva, questa risposta è cacheabile. L'obiettivo della risposta 410 è principalmente quello di aiutare gli amministratori di siti web a mantenere i loro siti, informando gli utenti che la risorsa non è più disponibile e che il proprietario del server desidera che tutti i collegamenti remoti che puntano a questa risorsa siano eliminati. Questo tipo di evento è comune nelle offerte a tempo limitato o nei servizi a pagamento. Allo stesso modo, la risposta 410 viene utilizzata per informare i client che, nel sito attuale del server, una risorsa appartenente a un particolare individuo non è più disponibile. Naturalmente, se gli amministratori del server desiderano contrassegnare tutte le risorse permanentemente non disponibili come '410 Gone' e quanto a lungo mantenere tale contrassegno è completamente a discrezione del proprietario del server. |
| 411 |
Il server rifiuta di accettare la richiesta senza un'intestazione Content-Length definita. Il client può ripetere la richiesta dopo l'aggiunta di un'intestazione Content-Length appropriata che indichi la lunghezza del corpo del messaggio della richiesta. |
| 412 |
Il server non soddisfa una o più delle condizioni pretenzionali fornite negli header della richiesta. Questo codice di stato consente al client di impostare condizioni pretenzionali nei metadati della richiesta (dati dell'intestazione della richiesta) quando ottiene le risorse, per evitare che il metodo di richiesta venga applicato a risorse che non intendeva. |
| 413 |
Il server rifiuta di elaborare la richiesta corrente perché le dimensioni dei dati dell'entità forniti nella richiesta superano i limiti che il server è disposto o in grado di elaborare. In questa situazione, il server può chiudere la connessione per evitare che il client continui a inviare tale richiesta. Se tale situazione è temporanea, il server dovrebbe restituire un header Retry-After per informare il client tra quanto tempo può provare di nuovo. |
| 414 |
La lunghezza dell'URI della richiesta supera i limiti che il server può elaborare, quindi il server rifiuta di fornire servizi per tale richiesta. Questo è raro e i casi comuni includono: un modulo che doveva usare il metodo POST viene inviato come GET, risultando in una query string (stringa di query) troppo lunga. URI di reindirizzamento "black hole", come un vecchio URI ripetutamente reindirizzato diventa parte nuova, causando l'URI a diventare troppo lungo dopo diversi reindirizzamenti. Un client sta cercando di sfruttare alcune vulnerabilità di sicurezza che esistono in alcuni server. Server che utilizzano un buffer di lunghezza fissa per leggere o elaborare le richieste URI, quando i parametri GET superano un certo valore, possono causare un overflow del buffer, portando all'esecuzione di codice arbitrario. Server senza tali vulnerabilità devono restituire un codice di stato 414. |
| 415 |
Il tipo dell'entità fornita nella richiesta non è supportato per il metodo e la risorsa richiesta, quindi la richiesta è stata rifiutata. |
| 416 |
Se la richiesta include un header Range e qualsiasi intervallo specificato in Range non coincide con l'intervallo disponibile della risorsa attuale e non è definito alcun If-Range nell'intestazione della richiesta, allora il server dovrebbe restituire il codice di stato 416. Se Range utilizza intervalli di byte, questa situazione si verifica quando la posizione del primo byte del range richiesto supera la lunghezza attuale della risorsa. Il server deve includere un'intestazione Content-Range nella risposta per indicare la lunghezza attuale della risorsa. Questa risposta è anche vietata dall'uso di multipart/byteranges come Content-Type. |
| 417 |
Il contenuto previsto specificato nell'header Expect non può essere soddisfatto dal server o il server è un server proxy e ha prove evidenti che nella prossima fase di routing, il contenuto di Expect non può essere soddisfatto. |
| 421 |
Il numero di connessioni dal client corrente all'indirizzo IP al server ha superato il limite massimo consentito dal server. Di solito, questo indirizzo IP si riferisce all'indirizzo client visto dal server (ad esempio, l'indirizzo gateway o proxy dell'utente). In questo caso, il conteggio delle connessioni potrebbe coinvolgere più utenti finali. |
| 422 |
Il formato della richiesta è corretto, ma non può essere elaborato a causa di errori semantici. (RFC 4918 WebDAV) 423 Locked la risorsa attuale è bloccata. (RFC 4918 WebDAV) |
| 424 |
La richiesta corrente è fallita a causa di un errore precedente, ad esempio PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Definito nella bozza delle collezioni avanzate WebDav, ma non appare nel Protocollo delle sequenze WebDAV (RFC 3658). |
| 426 |
Il client dovrebbe switchare a TLS/1.0. (RFC 2817) |
| 449 |
Esteso da Microsoft, indica che la richiesta dovrebbe essere ritentata dopo aver eseguito le operazioni appropriate. |
| 500 |
Il server ha incontrato una condizione inattesa che gli impedisce di completare l'elaborazione della richiesta. In generale, questo problema si verifica quando ci sono errori nel codice del server. |
| 501 |
Il server non supporta una funzionalità necessaria per la richiesta corrente. Quando il server non riconosce il metodo della richiesta e non può supportarlo per alcuna risorsa. |
| 502 |
Il server che funge da gateway o proxy ha ricevuto una risposta non valida dal server upstream mentre tentava di elaborare la richiesta. |
| 503 |
Il server non può attualmente elaborare la richiesta a causa di manutenzione temporanea o sovraccarico. Questa situazione è temporanea e verrà ripristinata dopo un po'. Se è possibile prevedere un ritardo, la risposta può includere un'header Retry-After per indicare quanto tempo ci vorrà. Se non viene fornita alcuna informazione Retry-After, il client deve gestirla come una risposta 500. Nota: l'esistenza del codice di stato 503 non implica che il server debba utilizzarlo quando è sovraccarico. Alcuni server semplicemente vogliono rifiutare la connessione del client. |
| 504 |
Il server che funge da gateway o proxy non è riuscito a ricevere una risposta tempestiva dal server upstream (ad es. URI identificato come HTTP, FTP, LDAP) o da un server ausiliario (ad es. DNS) mentre tentava di eseguire la richiesta. Nota: alcuni server proxy restituiscono un errore 400 o 500 durante un timeout di query DNS. |
| 505 |
Il server non supporta o rifiuta di supportare la versione HTTP utilizzata nella richiesta. Ciò implica che il server non può o non vuole utilizzare la stessa versione del client. La risposta dovrebbe includere un'entità che descrive perché la versione non è supportata e quali protocolli sono supportati dal server. |
| 506 |
Espanso dalla “Trasparente Content Negotiation Protocol” (RFC 2295), indica che si è verificato un errore di configurazione interno del server: la risorsa variabile di negoziazione richiesta è configurata per utilizzare se stessa nella negoziazione trasparente, quindi non è un obiettivo appropriato in una negoziazione. |
| 507 |
Il server non può memorizzare il contenuto necessario per completare la richiesta. Questa situazione è considerata temporanea. WebDAV (RFC 4918) |
| 509 |
Il server ha raggiunto un limite di larghezza di banda. Questo non è un codice di stato ufficiale, ma è ancora ampiamente utilizzato. |
| 510 |
Le politiche necessarie per ottenere le risorse non sono state soddisfatte. (RFC 2774) |