Suggerimento: Ctrl F Quick Find| Codice di stato Http | Significato del codice di stato |
|---|---|
| 100 | Il cliente dovrebbe continuare a inviare richieste. Questa risposta temporanea viene utilizzata per informare il client che parte della sua richiesta è stata ricevuta dal server e non è stata ancora respinta. Il client deve continuare a inviare il resto della richiesta o ignorare la risposta se la richiesta è già completa. Il server deve inviare una risposta finale al client dopo che la richiesta è stata completata. |
| 101 | Il server ha compreso la richiesta del client e notificherà al client di utilizzare un protocollo diverso per completare la richiesta aggiornando l'intestazione del messaggio. Dopo aver inviato l'ultima riga vuota della risposta, il server passerà al protocollo definito nell'intestazione Upgrade. Misure simili dovrebbero essere adottate solo quando è più vantaggioso passare a un nuovo protocollo. Ad esempio, passare a una nuova versione HTTP è più vantaggioso di una versione precedente o passare a un protocollo sincrono e in tempo reale per fornire risorse che sfruttano tali funzionalità. |
| 102 | Codice di stato esteso da WebDAV(RFC 2518), che indica che l'elaborazione continuerà. |
| 200 | La richiesta ha avuto esito positivo e l'intestazione o il corpo della risposta desiderata viene restituito con la risposta. |
| 201 | La richiesta è stata soddisfatta e una nuova risorsa è stata creata come richiesto dalla richiesta e il relativo URI è stato restituito con le informazioni dell'intestazione Posizione. Se le risorse richieste non possono essere stabilite in tempo, «202 Accettati» dovrebbero essere restituiti». |
| 202 | Il server ha accettato la richiesta ma non l'ha ancora elaborata. Così come può essere negato, alla fine la richiesta può o non può essere eseguita. Nel caso di operazioni asincrone, non c' è niente di più conveniente dell'invio di questo codice di stato. Lo scopo di una risposta che restituisce un codice di stato 202 è quello di consentire al server di accettare richieste per altri processi (come un'operazione basata su batch che viene eseguita solo una volta al giorno) senza dover mantenere il client connesso al server fino al completamento dell'operazione batch. Le risposte che accettano l'elaborazione richiesta e restituiscono un codice di stato 202 dovrebbero includere alcune informazioni nell'entità restituita che indicano lo stato corrente dell'elaborazione, nonché un puntatore al monitoraggio dello stato di elaborazione o alla previsione dello stato in modo che l'utente possa stimare se l'operazione è stata completata. |
| 203 | Il server ha elaborato con successo la richiesta, ma le meta informazioni dell'intestazione dell'entità restituite non sono un set deterministico valido sul server originale, ma una copia di una parte locale o di una terza parte. Le informazioni correnti possono essere un sottoinsieme o un superset della versione originale. Ad esempio, i metadati contenenti una risorsa possono far sì che il server di origine conosca il super delle meta informazioni. L'uso di questo codice di stato non è richiesto ed è appropriato solo se la risposta restituisce 200 OK senza questo codice di stato. |
| 204 | Il server ha elaborato la richiesta con successo, ma non ha bisogno di restituire alcun contenuto di entità e si aspetta di restituire le meta informazioni aggiornate. La risposta può restituire informazioni meta nuove o aggiornate sotto forma di un'intestazione di entità. Se tali informazioni di intestazione esistono, dovrebbero essere riprese con la variabile richiesta. Se il client è un browser, il browser utente dovrebbe conservare la pagina che ha inviato la richiesta senza apportare modifiche alla visualizzazione del documento, anche se le meta informazioni nuove o aggiornate devono essere applicate al documento nella visualizzazione attiva del browser utente in base alle specifiche. Poiché alla risposta 204 è vietato contenere qualsiasi 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. Tuttavia, a differenza di 204 risposte, le risposte che restituiscono questo codice di stato richiedono al richiedente di reimpostare la visualizzazione del documento. La risposta viene utilizzata principalmente per reimpostare il modulo immediatamente dopo aver accettato l'input dell'utente in modo che l'utente possa facilmente avviare un altro input. Come la risposta 204, anche alla risposta è vietato contenere qualsiasi corpo del messaggio e termina con la prima riga vuota dopo l'intestazione del messaggio. |
| 206 | Il server ha elaborato con successo alcune richieste GET. Gli strumenti di download HTTP come FlashGet e Xunlei utilizzano tutti questo tipo di risposta per implementare il download riprendibile o per suddividere un file di grandi dimensioni in più segmenti da scaricare contemporaneamente. La richiesta deve includere un header Range per specificare l’intervallo di contenuto che il client desidera ricevere, e può inoltre includere un header If-Range come header di richiesta condizionale. La risposta deve includere i seguenti campi dell’intestazione: Content-Range, che indica l’intervallo di contenuto restituito in questa risposta; se il campo Content-Type è multipart/byteranges per un download multi-part, ogni segmento multipart deve includere a sua volta un campo Content-Range per indicare l’intervallo di contenuto di quel segmento. Se la risposta include l’intestazione Content-Length, il suo valore deve corrispondere al numero effettivo di byte presente 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 differire da quelli presenti in altre risposte per le stesse variabili.Se la richiesta per questa risposta ha utilizzato la convalida della memorizzazione nella cache forte con l’header If-Range, la risposta non deve includere alcun altro header dell’entità. Al contrario, se la richiesta ha utilizzato la convalida della cache debole con l’header If-Range, la risposta non deve includere alcun altro header dell’entità. Ciò previene le incongruenze tra il contenuto dell’entità memorizzato nella cache e le informazioni aggiornate dell’intestazione dell’entità. In caso contrario, questa risposta deve includere tutti i campi dell’header di entità che sarebbero inclusi in una risposta 200 OK. Se l’intestazione ETag o Last-Modified non corrisponde esattamente, la cache del client deve astenersi dal combinare il contenuto restituito in una risposta 206 con qualsiasi contenuto precedentemente memorizzato nella cache. Qualsiasi cache che non supporti le intestazioni Range e Content-Range non deve memorizzare nella cache il contenuto restituito in una risposta 206. |
| 207 | Il codice di stato esteso da WebDAV(RFC 2518) indica che il corpo del messaggio successivo sarà un messaggio XML e potrebbe contenere una serie di codici di risposta indipendenti a seconda del numero di richieste secondarie precedenti. |
| 300 | La risorsa richiesta ha una gamma di informazioni di feedback alternative, ciascuna con il proprio indirizzo specifico e le informazioni di negoziazione guidate dal browser. L'utente o il browser può scegliere un indirizzo preferito per il reindirizzamento. A meno che non si tratti di una richiesta HEAD, la risposta dovrebbe includere l'entità di un elenco di proprietà e indirizzi delle risorse da cui l'utente o il browser possono selezionare l'indirizzo di reindirizzamento più appropriato. Il formato di questa entità è determinato dal formato definito dal tipo di contenuto. Il browser può effettuare automaticamente la selezione più appropriata in base al formato della risposta e alle capacità del browser. Naturalmente, la specifica RFC 2616 non specifica come dovrebbe avvenire tale selezione automatica. Se il server stesso ha già una selezione di feedback preferita, l'URI di questo feedback dovrebbe essere indicato nella Posizione; il browser può utilizzare questo valore di posizione come indirizzo per il reindirizzamento automatico. Inoltre, se non diversamente specificato, questa risposta è anche memorizzabile nella cache. |
| 301 | La risorsa richiesta è stata spostata in modo permanente in una nuova posizione e qualsiasi riferimento futuro a questa risorsa dovrebbe utilizzare uno dei diversi URI restituiti da questa risposta. Se possibile, il client con la funzione di modifica dei collegamenti dovrebbe modificare automaticamente l'indirizzo richiesto all'indirizzo inviato dal server. Se non diversamente specificato, questa risposta è anche memorizzabile nella cache. Il nuovo URI permanente deve essere restituito nel campo Posizione della risposta. A meno che non si tratti di una richiesta HEAD, l'entità che risponde dovrebbe contenere un collegamento ipertestuale al nuovo URI e una breve descrizione. Se questa non è una richiesta GET o HEAD, il browser vieta il reindirizzamento automatico a meno che non sia confermato dall'utente, poiché le condizioni della richiesta potrebbero cambiare di conseguenza. Nota: per alcuni browser che utilizzano il protocollo HTTP/1.0, quando la richiesta POST che inviano ottiene una risposta 301, la successiva richiesta di reindirizzamento diventerà GET. |
| 302 | La risorsa richiesta ora risponde temporaneamente alla richiesta da un URI diverso. Poiché tale reindirizzamento è temporaneo, il cliente dovrebbe continuare a inviare richieste future all'indirizzo originale. Questa risposta è memorizzabile nella cache solo se specificata in Cache-Controllo o Scade. Il nuovo URI temporaneo deve essere restituito nel campo Posizione della risposta. A meno che non si tratti di una richiesta HEAD, l'entità che risponde dovrebbe contenere un collegamento ipertestuale al nuovo URI e una breve descrizione. Se questa non è una richiesta GET o HEAD, il browser vieta il reindirizzamento automatico a meno che non sia confermato dall'utente, poiché le condizioni della richiesta potrebbero cambiare di conseguenza. Nota: Sebbene le specifiche RFC 1945 e RFC 2068 non consentano al client di modificare 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, indipendentemente dal metodo della richiesta originale. Sono stati aggiunti i codici di stato 303 e 307 per chiarire quale tipo di reazione il server si aspetta dal client. |
| 303 | La risposta corrispondente alla richiesta corrente può essere trovata su un altro URI e il client deve utilizzare GET per accedere a quella risorsa. Questo metodo esiste principalmente per consentire l'output di una richiesta POST attivata da uno script da reindirizzare a una nuova risorsa. Questo nuovo URI non è un riferimento alternativo alla risorsa originale. Allo stesso tempo, è vietato inserire nella cache 303 risposte. Naturalmente, la seconda richiesta (reindirizzamento) può essere memorizzata nella cache. Il nuovo URI dovrebbe essere restituito nel campo Posizione della risposta. A meno che non si tratti di una richiesta HEAD, l'entità che risponde dovrebbe contenere un collegamento ipertestuale al nuovo URI e una breve descrizione. Nota: molti browser prima di HTTP/1.1 non comprendono correttamente lo stato 303. Se è necessario considerare l'interazione con questi browser, i codici di stato 302 dovrebbero essere adeguati, poiché la maggior parte dei browser gestisce 302 risposte esattamente nel modo in cui la specifica di cui sopra richiede ai client di gestire 303 risposte. |
| 304 | Se il client invia una richiesta GET condizionale consentita e la rappresentazione della risorsa non è cambiata (dall’ultimo accesso o in base alle condizioni della richiesta), il server dovrebbe restituire questo codice di stato. Una risposta 304 non deve contenere un corpo del messaggio; pertanto, termina sempre con la prima riga vuota che segue gli header. La risposta deve includere l’intestazione seguente: Date, a meno che il server non disponga di un orologio. Se anche i server privi di orologio rispettano queste regole, i server proxy e i client possono aggiungere in modo indipendente un’intestazione Date alle intestazioni della risposta che ricevono (come specificato nella RFC 2068), e il meccanismo di caching funzionerà come previsto. ETag e/o Content-Location, nell’ipotesi che la stessa richiesta avrebbe altrimenti generato una risposta 200. Expires, Cache-Control e/o Vary, se i loro valori possono differire da quelli presenti in altre risposte per le stesse variabili.Se questa risposta alla richiesta utilizza una valida convalida della cache di tipo forte, la risposta non deve includere alcun altro header dell’entità; in caso contrario (ad esempio, se una richiesta GET condizionale utilizza una convalida della cache di tipo debole), la risposta non deve includere alcun altro header dell’entità. Ciò previene incongruenze tra il corpo dell’entità memorizzato nella cache e i campi dell’intestazione dell’entità aggiornati. Se una risposta 304 indica che una determinata entità non è attualmente memorizzata nella cache, il sistema di caching deve ignorare tale risposta e inviare nuovamente la richiesta senza alcun header condizionale. Se viene ricevuta una risposta 304 Not Modified che richiede l’aggiornamento di una voce della cache, il sistema di caching deve aggiornare l’intera voce in modo da riflettere i valori di tutti i campi che sono stati aggiornati nella risposta. |
| 305 | È necessario accedere alla risorsa richiesta tramite il proxy specificato. Il dominio Posizione fornirà le informazioni URI in cui si trova il proxy specificato e il destinatario deve inviare ripetutamente una richiesta separata per accedere alla risorsa corrispondente tramite questo proxy. Solo il server originale può stabilire una risposta 305. Nota: la RFC 2068 non ha esplicitamente 305 che la risposta ha lo scopo di reindirizzare una singola richiesta e può essere stabilita solo dal server di origine. Ignorare queste restrizioni potrebbe portare a gravi conseguenze sulla sicurezza. |
| 306 | Nell'ultima versione della specifica, 306 codici di stato non vengono più utilizzati. |
| 307 | La risorsa richiesta ora risponde temporaneamente alla richiesta da un URI diverso. Poiché tale reindirizzamento è temporaneo, il cliente dovrebbe continuare a inviare richieste future all'indirizzo originale. Questa risposta è memorizzabile nella cache solo se specificata in Cache-Controllo o Scade. Il nuovo URI temporaneo deve essere restituito nel campo Posizione della risposta. A meno che non si tratti di una richiesta HEAD, l'entità che risponde dovrebbe contenere un collegamento ipertestuale al nuovo URI e una breve descrizione. Poiché alcuni browser non sono in grado di riconoscere la risposta 307, è necessario aggiungere le informazioni necessarie sopra menzionate in modo che l'utente possa comprendere ed emettere una richiesta di accesso al nuovo URI. Se questa non è una richiesta GET o HEAD, il browser vieta il reindirizzamento automatico a meno che non sia confermato dall'utente, poiché le condizioni della richiesta potrebbero cambiare di conseguenza. |
| 400 | 1. Errore semantico, la richiesta corrente non può essere compresa dal server. Se non modificato, il cliente non deve presentare questa richiesta ripetutamente. 2. Il parametro di richiesta non è corretto. |
| 401 | La richiesta corrente richiede l'autenticazione dell'utente. La risposta deve contenere un'intestazione WWW-Authenticate per la risorsa richiesta per chiedere informazioni all'utente. Il client può inviare ripetutamente una richiesta contenente le informazioni appropriate dell'intestazione di autorizzazione. Se la richiesta corrente contiene già certificati di autorizzazione, la risposta 401 indica che il server ha verificato che tali certificati sono stati rifiutati. Se la risposta 401 contiene lo stesso challenge di autenticazione della risposta precedente e il browser ha tentato l'autenticazione almeno una volta, il browser deve mostrare all'utente le informazioni sull'entità contenute nella risposta, poiché queste informazioni sull'entità possono contenere informazioni diagnostiche pertinenti. Cfr. RFC 2617. |
| 402 | Questo codice di stato è riservato per eventuali esigenze future. |
| 403 | Il server ha capito la richiesta, ma si rifiuta di eseguirla. A differenza delle risposte 401, l'autenticazione non aiuta e la richiesta non deve essere inviata ripetutamente. Se questa non è una richiesta HEAD e il server vuole essere in grado di spiegare 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 ottenesse alcuna informazione. |
| 404 | La richiesta non è riuscita perché la risorsa richiesta non è stata trovata sul server. Nessuna informazione può dire all'utente se la situazione è temporanea o permanente. Se il server conosce la situazione, dovrebbe utilizzare il codice di stato 410 per informare la vecchia risorsa che non è stata permanentemente disponibile a causa di alcuni problemi del meccanismo di configurazione interno e non ha alcun indirizzo da saltare. 404 questo codice di stato è ampiamente utilizzato quando il server non vuole rivelare il motivo per cui la richiesta è stata rifiutata o non è disponibile alcuna altra risposta adeguata. |
| 405 | Il metodo di richiesta specificato nella riga di richiesta non può essere utilizzato per richiedere la risorsa corrispondente. La risposta deve restituire un'intestazione Consenti che indica un elenco di metodi di richiesta che la risorsa corrente può accettare. Poiché i metodi PUT e DELETE scrivono sulle risorse sul server, la maggior parte dei server Web non supporta o non consente i metodi di richiesta di cui sopra per impostazione predefinita e vengono restituiti 405 errori per tali richieste. |
| 406 | Le caratteristiche del contenuto della risorsa richiesta non soddisfano le condizioni nell'intestazione della richiesta, quindi 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 un elenco di proprietà e indirizzi di entità da cui l'utente o il browser possono scegliere il più appropriato. Il formato dell'entità è determinato dal tipo di supporto 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 selezioni automatiche. |
| 407 | Simile a una risposta 401, tranne per il fatto che il client deve autenticarsi sul server proxy. Il server proxy deve restituire un Proxy-Autenticato per la richiesta di identità. Il client può restituire un'intestazione Proxy-Autorizzazione per la verifica. Vedi RFC 2617. |
| 408 | Richiesta scadente. Il client non è riuscito a completare l'invio di una richiesta entro il periodo di timeout configurato del server. Il cliente può ripresentare questa 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 l'utente dovrebbe essere in grado di risolvere il conflitto e inviare nuovamente la nuova richiesta. La risposta dovrebbe contenere informazioni sufficienti per consentire all'utente di scoprire la fonte del conflitto. I conflitti si verificano in genere nell'elaborazione delle richieste PUT. Ad esempio, in un ambiente in cui viene utilizzato il controllo della versione e le informazioni sulla versione allegate a una richiesta di modifica inviata PUT per una particolare risorsa sono in conflitto con una richiesta precedente (di terze parti), il server dovrebbe restituire un errore 409 che informa l'utente che la richiesta non può essere completata. A questo punto, è probabile che l'entità di risposta conterrà un confronto delle differenze tra le due versioni in conflitto in modo che l'utente possa ripresentare la nuova versione unita. |
| 410 | La risorsa richiesta non è più disponibile sul server e non esiste un indirizzo di inoltro noto. Tale situazione dovrebbe essere considerata permanente. Se possibile, il client con la funzione di modifica dei collegamenti dovrebbe rimuovere tutti i riferimenti a questo indirizzo con l'autorizzazione dell'utente. Se il server non sa o non riesce a determinare se la condizione è permanente, è necessario utilizzare il codice di stato 404. Salvo diversa indicazione, questa risposta è memorizzabile nella cache. Lo scopo della risposta 410 è principalmente quello di aiutare il webmaster a mantenere il sito Web, informare l'utente che la risorsa non è più disponibile e il proprietario del server desidera che tutte le connessioni remote a questa risorsa vengano eliminate. Tali incidenti sono comuni nei servizi a valore aggiunto a tempo limitato. Allo stesso modo, 410 risposte vengono utilizzate per informare il client che una risorsa originariamente appartenuta a un individuo non è più disponibile nel sito del server corrente. Ovviamente, se è necessario contrassegnare tutte le risorse permanentemente non disponibili come "410 Gone" e per quanto tempo è necessario mantenere questo marchio, dipende interamente dal proprietario del server. |
| 411 | Il server ha rifiutato di accettare la richiesta senza definire l'intestazione Content-Length. Dopo aver aggiunto un'intestazione Contenuto-Lunghezza valida che indica la lunghezza del corpo del messaggio di richiesta, il client può inviare nuovamente la richiesta. |
| 412 | Il server non soddisfa uno o più prerequisiti quando verifica che siano forniti nei campi di intestazione della richiesta. Questo codice di stato consente al client di impostare le precondizioni nelle meta informazioni (dati del campo di intestazione di richiesta) della richiesta durante l'acquisizione della risorsa, impedendo così che il metodo di richiesta venga applicato a risorse diverse dal contenuto desiderato. |
| 413 | Il server si rifiuta di elaborare la richiesta corrente perché la richiesta sta inviando più dati di entità di quelli che il server è disposto o in grado di elaborare. In questo caso, il server può chiudere la connessione per impedire al client di continuare a inviare la richiesta. Se la condizione è temporanea, il server deve restituire un'intestazione di risposta Riprova dopo per comunicare al client quanto tempo può richiedere per riprovare. |
| 414 | La lunghezza dell'URI richiesto supera la lunghezza che il server può analizzare, quindi il server si rifiuta di soddisfare la richiesta. Questo è relativamente raro. Gli scenari tipici includono invii di moduli che dovrebbero utilizzare il metodo POST ma invece utilizzare GET, risultando in una stringa di query eccessivamente lunga. L'URI di reindirizzamento "Black hole", in cui ogni reindirizzamento aggiunge l'URI precedente a quello nuovo, può comportare un URI eccessivamente lungo dopo diversi reindirizzamenti. Il client sta tentando di sfruttare una vulnerabilità di sicurezza presente su determinati server per attaccarli. Questi server utilizzano buffer di lunghezza fissa per leggere o elaborare l'URI dei messaggi di richiesta. Quando il numero di caratteri che seguono il metodo GET supera una certa soglia, può verificarsi un overflow del buffer, che potrebbe portare all'esecuzione di codice arbitrario [1]. I server che non dispongono di questo tipo di vulnerabilità devono restituire un codice di stato 414. |
| 415 | Per il metodo attualmente richiesto e la risorsa richiesta, l'entità presentata nella richiesta non è nel formato supportato nel server, quindi la richiesta viene rifiutata. |
| 416 | Se la richiesta contiene l'intestazione della richiesta Range, qualsiasi intervallo di dati specificato nell'intervallo non coincide con l'intervallo disponibile della risorsa corrente e l'intestazione della richiesta If-Range non è definita nella richiesta, il server deve restituire il codice di stato 416. Se l'intervallo utilizza un intervallo di byte, la prima posizione di byte di tutti gli intervalli di dati specificati nella richiesta supera la lunghezza della risorsa corrente. Il server deve includere anche un'intestazione di entità Content-Range insieme al codice di stato 416 per indicare la lunghezza della risorsa corrente. A questa risposta è inoltre vietato utilizzare multipart/byteranges come tipo di contenuto. |
| 417 | Il contenuto previsto specificato nell'intestazione della richiesta Expect non può essere soddisfatto dal server o il server è un server proxy che ha prove evidenti che il contenuto Expect non può essere soddisfatto nel nodo successivo del percorso corrente. |
| 421 | Il numero di connessioni dall'indirizzo IP del client corrente al server supera il massimo consentito dal server. Generalmente, l'indirizzo IP qui si riferisce all'indirizzo del client visto dal server (come il gateway o l'indirizzo del server proxy dell'utente). In questo caso, il calcolo del numero di connessioni può coinvolgere più di un utente finale. |
| 422 | Il numero di connessioni dall'indirizzo IP del client corrente al server supera il massimo consentito dal server. Generalmente, l'indirizzo IP qui si riferisce all'indirizzo del client visto dal server (come il gateway o l'indirizzo del server proxy dell'utente). In questo caso, il calcolo del numero di connessioni può coinvolgere più di un utente finale. |
| 422 | Il formato della richiesta è corretto, ma non può essere elaborato a causa di errori semantici. (RFC 4918 WebDAV) 423 Bloccato La risorsa corrente è bloccata. (RFC 4918 WebDAV) |
| 424 | La richiesta corrente non è riuscita a causa di un errore che si è verificato in una richiesta precedente, ad esempio un PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Definito nella bozza delle raccolte avanzate di Webnot, ma non nel protocollo WebDAV Sequence Set (RFC 3658). |
| 426 | Il client dovrebbe passare a TLS/1.0. (RFC 2817) |
| 449 | Per estensione Microsoft, la richiesta del delegato deve essere riprovata dopo aver eseguito l'azione appropriata. |
| 500 | Il server ha riscontrato una condizione imprevista che gli ha impedito di completare la richiesta. In generale, questo problema si verificherà quando il codice del programma del server è sbagliato. |
| 501 | Il server non supporta una funzionalità richiesta dalla richiesta corrente. Quando il server non riconosce il metodo richiesto e non può supportare la sua richiesta di alcuna risorsa. |
| 502 | Un server che opera come gateway o proxy riceve una risposta non valida da un server a monte quando tenta di eseguire una richiesta. |
| 503 | Il server al momento non è in grado di elaborare le richieste a causa di una manutenzione temporanea o di un sovraccarico. Questa situazione è temporanea e si risolverà dopo un certo periodo di tempo. Se il ritardo può essere stimato, la risposta può includere un header Retry-After per indicare la durata del ritardo. Se l’intestazione Retry-After non è presente, il client dovrebbe trattare la risposta come se fosse uno stato 500. Nota: L’esistenza del codice di stato 503 non implica che un server debba utilizzarlo quando è sovraccarico. Alcuni server sono semplicemente intenzionati a rifiutare le connessioni dei client. |
| 504 | Quando un server che funge da gateway o da proxy tenta di soddisfare una richiesta, non riesce a ricevere tempestivamente una risposta da un server upstream (identificato dall’URI, come un server HTTP, FTP o LDAP) o da un server ausiliario (come un server DNS). Nota: Alcuni server proxy restituiscono un errore 400 o 500 quando una query DNS scade. |
| 505 | Il server non supporta, oppure si rifiuta di supportare, la versione HTTP utilizzata nella richiesta. Ciò suggerisce che il server non può o non vuole utilizzare la stessa versione del protocollo del client. La risposta deve includere un elemento che spieghi il motivo per cui la versione non è supportata e quali protocolli il server effettivamente supporta. |
| 506 | Esteso dal Transparent Content Negotiation Protocol (RFC 2295), il server delegato ha un errore di configurazione interno: la risorsa dell'argomento di negoziazione richiesto è configurata per l'utilizzo di se stessa nella negoziazione del contenuto trasparente e quindi non è un punto focale appropriato in un processo di negoziazione. |
| 507 | Il server non è stato in grado di memorizzare il contenuto necessario per completare la richiesta. Questa situazione è considerata temporanea. WebDAV(RFC 4918) |
| 509 | Il server raggiunge il limite di larghezza di banda. Questo non è un codice di stato ufficiale, ma è ancora ampiamente utilizzato. |
| 510 | Le strategie necessarie per ottenere risorse non sono soddisfatte. (RFC 2774) |
Link amici:iCMS