Strumenti online
Codici 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 notificherà al client tramite l'intestazione Upgrade che è stato utilizzato un protocollo diverso per completare la richiesta. Dopo aver inviato l'ultima riga vuota della risposta, il server passerà ai protocolli definiti nell'intestazione Upgrade. Questa operazione va fatta solo se è più vantaggioso passare al nuovo protocollo. Ad esempio, il passaggio a una nuova versione di HTTP può essere più vantaggioso di 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 è andata a buon fine e le intestazioni o il corpo dei dati desiderati dalla richiesta saranno restituiti con la risposta.
201 La richiesta è stata soddisfatta e una nuova risorsa è stata creata in risposta alla richiesta e il suo URI è stato restituito con l'intestazione Location. Se la risorsa richiesta non può essere creata in tempo, verrà restituita la seguente risposta'202 Accepted'。
202 Il server ha accettato la richiesta, ma non l'ha ancora elaborata. Così come può essere rifiutata, la richiesta può essere eseguita o meno. Nel caso di operazioni asincrone, non c'è niente di più comodo che inviare questo codice di stato. Lo scopo di restituire una risposta 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 che il client debba mantenere una connessione 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 o meno.
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 dell'originale. Ad esempio, i metadati contenenti risorse possono far sì che il server di origine conosca le meta-informazioni super. 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 queste 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 alla visualizzazione del documento, anche se le meta-informazioni nuove o aggiornate DOVREBBERO, secondo le specifiche, 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 gestisce con successo la richiesta e non restituisce nulla. Tuttavia, a differenza della risposta 204, la risposta che restituisce questo codice di stato chiede al richiedente di reimpostare la visualizzazione del documento. Questa risposta è usata principalmente per reimpostare il modulo subito dopo aver accettato l'input dell'utente, in modo che l'utente 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 file di grandi dimensioni in più 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 o, nel caso di download multipart con un Content-Type di multipart/byteranges, un campo Content-Range in ogni segmento multipart per indicare 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. Expires, Cache-Control e/o Vary, se i loro valori possono essere diversi da quelli di altre risposte precedenti con le stesse variabili. Questa risposta non dovrebbe contenere altre intestazioni di entità se la richiesta utilizza una validazione forte della cache If-Range e non dovrebbe contenere altre intestazioni di entità se la richiesta utilizza una 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 dell'intestazione dell'entità che avrebbero dovuto essere restituiti nella risposta 200. Se le intestazioni ETag o Last-Modified non corrispondono esattamente, la cache lato client dovrebbe impedire la combinazione del 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 Codici di stato estesi da WebDAV(RFC 2518) Il codice di stato, come esteso da WebDAV, 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 risposte alternative, ognuna con il suo indirizzo specifico e le sue informazioni di negoziazione guidate dal browser. Spetta all'utente o al browser scegliere l'indirizzo preferito per il reindirizzamento. A meno che non si tratti di una richiesta HEAD, la risposta dovrebbe includere un'entità che è un elenco di caratteristiche della risorsa e di indirizzi da cui l'utente o il browser possono scegliere 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 debba avvenire questa selezione automatica. Se il server stesso ha già un'opzione di ritorno preferita, l'URI del ritorno deve essere specificato nella Location; i browser possono usare questo valore di Location come indirizzo per il reindirizzamento automatico. Inoltre, la risposta è memorizzabile nella cache, se non diversamente specificato.
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 è 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à 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. La 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. 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 si trova in un altro URI e il client deve accedere a tale risorsa utilizzando GET. Questo metodo esiste principalmente per consentire di reindirizzare l'output di una richiesta POST attivata da script a una nuova risorsa. Questo nuovo URI non è un riferimento sostitutivo 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 all'HTTP/1.1 non comprendono correttamente lo stato 303. Se è necessario interagire con questi browser, il codice di stato 302 dovrebbe funzionare, poiché la maggior parte dei browser gestisce la risposta 302 esattamente nel modo in cui la specifica precedente richiede al client di gestire la risposta 303.
304 Questo codice di stato dovrebbe essere restituito dal server se il client invia una richiesta GET condizionale e la richiesta è consentita, e il contenuto del documento non è cambiato (né dall'ultima visita né in base alle condizioni della richiesta). È vietato che le risposte 304 contengano un corpo del messaggio e quindi terminano sempre con la prima riga vuota dopo l'intestazione del messaggio. La risposta deve contenere le seguenti informazioni di intestazione: Data, a meno che il server non abbia 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 dovuto restituire una risposta 200. Expires, Cache-Control e/o Vary, se i loro valori possono essere diversi da quelli di altre risposte precedenti con le stesse variabili. Se la richiesta di risposta utilizza una convalida forte della cache, la risposta non deve contenere intestazioni aggiuntive di entità; in caso contrario (ad esempio, una richiesta GET condizionale utilizza una convalida debole della cache), la risposta non può contenere intestazioni aggiuntive 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 un proxy specificato. Il campo Location fornirà informazioni sull'URI del proxy specificato e 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 di origine. Ignorare queste restrizioni può portare a gravi conseguenze per la sicurezza.
306 Nell'ultima versione della specifica, il codice di stato 306 non viene più utilizzato.
307 Le risorse richieste rispondono ora temporaneamente a richieste provenienti da URI diversi. Poiché questo reindirizzamento è temporaneo, 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, errore semantico, la richiesta corrente non può essere compresa dal server. Se non viene modificata, il client non deve ripetere la richiesta. 2, i parametri della richiesta sono errati.
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ò ripresentare una richiesta con le informazioni appropriate dell'intestazione Authorisation. Se la richiesta corrente contiene già credenziali di autorizzazione, una risposta 401 significa che il server verifica che tali credenziali sono state rifiutate. Se la risposta 401 contiene la stessa richiesta di autenticazione della risposta precedente e il browser ha già effettuato almeno un tentativo di autenticazione, il browser deve mostrare all'utente le informazioni sull'entità contenute nella risposta, in quanto queste informazioni possono contenere informazioni diagnostiche rilevanti. Vedere RFC 2617.
402 Questo codice di stato è riservato per eventuali esigenze future.
403 Il server ha compreso la richiesta, ma rifiuta di eseguirla. A differenza di una risposta 401, l'autenticazione non fornisce alcun aiuto e la richiesta non deve essere ripresentata. Se non si tratta di una richiesta HEAD e il server vuole essere in grado di dire perché la richiesta non può essere eseguita, il motivo del rifiuto deve essere descritto nell'entità. Naturalmente, il server può anche restituire una risposta 404 se non vuole che il client ottenga alcuna informazione.
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 il server che la vecchia risorsa è permanentemente non disponibile 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 è disponibile un'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'intestazione Allow che indica l'elenco dei metodi di richiesta accettabili per la risorsa corrente. Poiché i metodi PUT e DELETE scrivono sulla risorsa sul server, la maggior parte dei server web non li supporta o 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à che contiene le caratteristiche più appropriate dell'entità e un elenco di indirizzi tra cui l'utente o il browser può scegliere. Il formato dell'entità è determinato dal tipo di media definito nell'intestazione Content-Type. Il browser può fare la scelta migliore in base al formato e alle proprie capacità. Tuttavia, la specifica non definisce alcun criterio per effettuare tali scelte automatiche.
407 Simile alla risposta 401, tranne per il fatto che il client deve autenticarsi con il server proxy. Il server proxy DEVE restituire un Proxy-Authenticate per l'interrogazione dell'identità. Il client può restituire un'intestazione Proxy-Authorisation per l'autenticazione. Vedere RFC 2617.
408 Timeout della richiesta. Il client non ha completato una richiesta entro il tempo che il server era disposto ad attendere. Il client può ripresentare la richiesta in qualsiasi momento senza apportare modifiche.
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 spesso nell'elaborazione delle richieste PUT. Ad esempio, in un ambiente di controllo delle versioni, una PUT inviata per modificare una particolare risorsa con informazioni sulla versione in conflitto con una richiesta precedente (di terzi) 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 unificata.
410 La risorsa richiesta non è più disponibile sul server e non esiste un indirizzo di inoltro noto. Questa situazione 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 la condizione è permanente, si deve utilizzare un codice di stato 404. Se non diversamente specificato, questa risposta è memorizzabile nella cache. Lo scopo della risposta 410 è principalmente quello di aiutare il webmaster a mantenere il sito, informando l'utente che la risorsa non è più disponibile e che il proprietario del server desidera che anche tutte le connessioni remote alla risorsa vengano eliminate. Questo tipo di evento è comune nei servizi a valore aggiunto e a tempo limitato. Analogamente, la risposta 410 viene utilizzata per notificare al client che una risorsa appartenente a un individuo non è più disponibile nel sito del server corrente. Naturalmente, è importante anche stabilire se tutte le risorse permanentemente non disponibili debbano essere contrassegnate come tali e per quanto tempo debbano essere mantenute tali.'410 Gone'， e per quanto tempo debba essere mantenuto, dipende esclusivamente dal proprietario del server.
411 Il server rifiuta di accettare richieste senza l'intestazione Content-Length definita. Il client può ripresentare la richiesta dopo aver aggiunto un'intestazione Content-Length valida che indichi la lunghezza del corpo del messaggio di richiesta.
412 Il server non ha soddisfatto uno o più dei prerequisiti indicati nel campo dell'intestazione della richiesta durante la sua convalida. Questo codice di stato consente al client di impostare i prerequisiti nelle meta-informazioni della richiesta (dati del campo dell'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 più dati fisici di quelli 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 la situazione è temporanea, il server deve restituire un'intestazione Retry-After per informare il client di quanto tempo ha a disposizione per riprovare.
414 L'URI della richiesta è più lungo di quanto il server possa interpretare, quindi il server rifiuta di servire la richiesta. Si tratta di un caso raro, che di solito si verifica 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 per 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 richiesto, il che può causare un buffer overflow quando il parametro GET supera un certo valore, portando all'esecuzione di codice arbitrario.[1]。 I server privi di queste vulnerabilità dovrebbero restituire un codice di stato 414.
415 Per il metodo e la risorsa richiesti, l'entità presentata nella richiesta non è in un formato supportato dal server e la richiesta viene rifiutata.
416 Se la richiesta contiene un'intestazione di richiesta Range e gli intervalli di dati specificati in Range non coincidono con gli intervalli disponibili per la risorsa corrente e la richiesta non definisce un'intestazione di richiesta If-Range, il server dovrebbe restituire un codice di stato 416. Se Range utilizza intervalli di byte, il server dovrebbe restituire un codice di stato 416. Se Range utilizza intervalli di byte, significa che il primo byte di tutti gli intervalli di dati specificati nella richiesta supera la lunghezza della risorsa corrente. Il server dovrebbe 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 il 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 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, più di un utente finale può essere coinvolto nel conteggio delle connessioni.
422 Il numero di connessioni dall'indirizzo IP del client corrente al server 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, più di un utente finale potrebbe essere coinvolto nel conteggio delle connessioni.
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) 423 Bloccato
424 La richiesta corrente è fallita a causa di un errore 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 incontrato 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 funzione necessaria per la richiesta in corso. Quando il server non riconosce il metodo richiesto e non può 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 un certo periodo di tempo. Se si prevede un ritardo, la risposta può includere un'intestazione Retry-After per indicare il ritardo. Se l'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 vogliono semplicemente negare la connessione al client.
504 Un server che funge da 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 finisce.
505 Il server non supporta o rifiuta di supportare la versione di HTTP utilizzata nella richiesta. Ciò implica che il server non è in grado 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 Transparent Content Negotiation e non è quindi 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)
Accesso ai documenti: