I tuoi adesivi

Fissa qui gli strumenti. Restano salvati in questo browser.

Elenco dei codici di stato HTTP

I codici di stato HTTP da 100 a 511, con cosa significa ciascuno per uno sviluppatore e la RFC che lo definisce, più i codici non standard usati da nginx, Cloudflare e altri prodotti.

78 codici di stato.

1xx Informazioni

Il server ha ricevuto la richiesta e la sta ancora elaborando. Sono risposte provvisorie, inviate prima di quella definitiva.

100 Continue: Il server ha ricevuto gli header della richiesta e il client può inviare il body. Il client lo chiede inviando Expect: 100-continue prima di un upload di grandi dimensioni. RFC 9110
101 Switching Protocols: Il server accetta di cambiare protocollo su questa connessione, come chiesto dall'header Upgrade. Una connessione WebSocket inizia così. RFC 9110
102 Processing: Il server ha accettato una richiesta WebDAV e ci sta ancora lavorando, quindi il client non deve andare in timeout. L'attuale specifica WebDAV non lo include più e viene inviato di rado. RFC 2518
103 Early Hints: Viene inviato prima della risposta definitiva, con header Link, così il browser può iniziare a precaricare risorse o ad aprire connessioni mentre il server prepara la pagina. RFC 8297

2xx Successo

La richiesta è stata ricevuta, compresa e accettata.

200 OK: La richiesta è andata a buon fine. Il body contiene il risultato: la risorsa per GET o l'esito dell'azione per POST. RFC 9110
201 Created: La richiesta ha creato una nuova risorsa. Di solito l'header Location ne indica l'URL. RFC 9110
202 Accepted: La richiesta è stata accettata per un'elaborazione che non è terminata e che può ancora fallire. È tipico dei lavori messi in coda. RFC 9110
203 Non-Authoritative Information: La richiesta è andata a buon fine, ma un proxy ha modificato la risposta inviata dal server di origine. RFC 9110
204 No Content: La richiesta è andata a buon fine e non c'è nessun body da inviare. È comune per DELETE, e per PUT o PATCH quando il client ha già il nuovo stato. RFC 9110
205 Reset Content: La richiesta è andata a buon fine e il client deve reimpostare la vista che l'ha inviata, per esempio svuotando un modulo. Non c'è body. RFC 9110
206 Partial Content: Il body contiene solo l'intervallo di byte chiesto dall'header Range. Si usa per riprendere i download e per spostarsi all'interno di un video. RFC 9110
207 Multi-Status: Il body è un documento XML con uno stato separato per ciascuna di più risorse. Lo usa WebDAV. RFC 4918
208 Already Reported: All'interno di una risposta WebDAV Multi-Status, indica i membri di un binding già elencati, così da non ripeterli. RFC 5842
226 IM Used: Il body è il risultato di una o più instance manipulation, come un delta, applicate alla risorsa corrente. Fa parte del delta encoding in HTTP, che è implementato di rado. RFC 3229

3xx Reindirizzamento

Il client deve fare un ulteriore passo per completare la richiesta, di solito una richiesta a un altro URL.

300 Multiple Choices: La risorsa ha più rappresentazioni e il client può sceglierne una. Si usa poco, perché non esiste un modo standard per fare la scelta. RFC 9110
301 Moved Permanently: Redirect permanente: la risorsa ha un nuovo URL, indicato nell'header Location, e di solito i motori di ricerca indicizzano quell'URL al posto del vecchio. Seguendo il redirect, i client possono trasformare un POST in GET; usa 308 per mantenere il metodo. RFC 9110
302 Found: Redirect temporaneo: per ora la risorsa si trova a un altro URL, indicato nell'header Location. Seguendo il redirect, i client possono trasformare un POST in GET; usa 307 per mantenere il metodo. RFC 9110
303 See Other: La risposta si trova a un altro URL, che il client deve richiedere con GET. È il redirect abituale dopo il POST di un modulo, così ricaricando la pagina il modulo non viene inviato di nuovo. RFC 9110
304 Not Modified: La copia nella cache del client è ancora aggiornata, quindi non viene inviato nessun body. Risponde a una richiesta condizionale fatta con If-None-Match o If-Modified-Since. RFC 9110
305 Use Proxy: La risorsa va raggiunta attraverso il proxy indicato nell'header Location. È deprecato per motivi di sicurezza, e i client non dovrebbero farci affidamento. RFC 9110
306 (Unused): Una versione precedente della specifica usava questo codice. Non si usa più, e il numero resta riservato. RFC 9110
307 Temporary Redirect: La risorsa si trova temporaneamente a un altro URL, e il client deve ripetere lì la richiesta con lo stesso metodo e lo stesso body. RFC 9110
308 Permanent Redirect: La risorsa ha un nuovo URL permanente, e il client deve ripetere lì la richiesta con lo stesso metodo e lo stesso body. RFC 9110

4xx Errore del client

Il problema è dal lato del client: la richiesta è malformata, non ha i permessi necessari o chiede qualcosa che non si può servire.

400 Bad Request: Il server non può elaborare la richiesta perché è malformata: la sintassi è sbagliata, il framing non è valido o non è possibile fare il parsing del body. RFC 9110
401 Unauthorized: Alla richiesta mancano credenziali valide. L'header WWW-Authenticate della risposta indica come autenticarsi. Nonostante il nome, il codice riguarda l'autenticazione, non i permessi. RFC 9110
402 Payment Required: Riservato per uso futuro. Alcune API lo inviano quando un abbonamento è scaduto o una quota a pagamento è esaurita. RFC 9110
403 Forbidden: Il server ha capito la richiesta e la rifiuta. Se la richiesta conteneva credenziali, queste non danno accesso a questa risorsa, e inviarle di nuovo non serve. RFC 9110
404 Not Found: Il server non ha nulla a questo URL, o non vuole rivelare di averlo. Il codice non dice se l'assenza è permanente. RFC 9110
405 Method Not Allowed: La risorsa esiste ma non supporta questo metodo. L'header Allow elenca i metodi supportati. RFC 9110
406 Not Acceptable: Il server non può produrre una risposta che soddisfi gli header Accept, Accept-Language o Accept-Encoding della richiesta. RFC 9110
407 Proxy Authentication Required: Come 401, ma il client deve autenticarsi presso il proxy, come descrive l'header Proxy-Authenticate. RFC 9110
408 Request Timeout: Il server non ha ricevuto la richiesta completa entro il tempo che era disposto ad attendere, e chiude la connessione. RFC 9110
409 Conflict: La richiesta è in conflitto con lo stato attuale della risorsa, per esempio una modifica basata su una versione superata o il duplicato di un valore che deve essere univoco. RFC 9110
410 Gone: La risorsa era qui ed è stata rimossa definitivamente. A differenza di 404, dice ai client e ai motori di ricerca che possono abbandonare l'URL. RFC 9110
411 Length Required: Il server rifiuta la richiesta perché non ha l'header Content-Length. RFC 9110
412 Precondition Failed: Una condizione in If-Match, If-Unmodified-Since o in un header simile è risultata falsa, quindi la richiesta non è stata applicata. Serve a evitare di sovrascrivere una modifica fatta da qualcun altro. RFC 9110
413 Content Too Large: Il body della richiesta è più grande di quanto il server accetti, di solito per un limite di upload nel server o in un proxy che gli sta davanti. Prima si chiamava Payload Too Large. RFC 9110
414 URI Too Long: L'URL è più lungo di quanto il server accetti. Spesso significa che dati che andavano nel body di un POST sono finiti nella query string. RFC 9110
415 Unsupported Media Type: Il server non accetta il formato del body della richiesta, dichiarato nell'header Content-Type o Content-Encoding. RFC 9110
416 Range Not Satisfiable: L'header Range chiede byte che si trovano fuori dalla risorsa. RFC 9110
417 Expectation Failed: Il server non può soddisfare il requisito indicato nell'header Expect della richiesta. RFC 9110
418 I'm a teapot: Un pesce d'aprile dell'Hyper Text Coffee Pot Control Protocol, in cui una teiera si rifiuta di preparare il caffè. La RFC 9110 indica il numero come inutilizzato e lo tiene riservato, perché è stato usato per scherzo troppo spesso per dargli un altro significato. RFC 2324, RFC 9110
421 Misdirected Request: La richiesta è arrivata a un server che non è configurato per rispondere per questo nome host. Può succedere quando un browser riusa una connessione HTTP/2 per un altro host; il client può riprovare su una nuova connessione. RFC 9110
422 Unprocessable Content: La sintassi della richiesta è corretta ma il contenuto non è valido, per esempio un body JSON che non supera la validazione. Viene da WebDAV, dove si chiamava Unprocessable Entity. RFC 9110, RFC 4918
423 Locked: La risorsa WebDAV è bloccata, quindi non le si può applicare il metodo. RFC 4918
424 Failed Dependency: Il metodo non è stato eseguito su questa risorsa WebDAV perché è fallita un'altra azione da cui dipendeva. RFC 4918
425 Too Early: Il server non elabora una richiesta arrivata nei TLS early data, perché potrebbe essere un replay. Il client deve inviarla di nuovo dopo la fine dell'handshake. RFC 8470
426 Upgrade Required: Il server rifiuta la richiesta su questo protocollo e indica, nell'header Upgrade, il protocollo a cui il client deve passare. RFC 9110
428 Precondition Required: Il server richiede che la richiesta sia condizionale, per esempio con If-Match, così che un aggiornamento non possa sovrascrivere silenziosamente una versione più recente. RFC 6585
429 Too Many Requests: Il client ha inviato troppe richieste in un certo intervallo di tempo: è il cosiddetto rate limiting. L'header Retry-After può indicare quanto attendere. RFC 6585
431 Request Header Fields Too Large: Gli header nel loro insieme, o uno di essi, sono più grandi di quanto il server accetti. Una causa frequente è un cookie troppo grande. RFC 6585
451 Unavailable For Legal Reasons: Il server nega l'accesso per un obbligo legale, come l'ordine di un tribunale. Il numero richiama il romanzo Fahrenheit 451. RFC 7725

5xx Errore del server

La richiesta può anche essere valida, ma il server o un gateway che gli sta davanti non è riuscito a soddisfarla.

500 Internal Server Error: Il server si è trovato in una condizione inattesa, spesso un'eccezione non gestita. La causa va cercata nei log del server. RFC 9110
501 Not Implemented: Il server non supporta la funzionalità che serve alla richiesta, per esempio un metodo che non riconosce. RFC 9110
502 Bad Gateway: Un gateway o un proxy ha ricevuto una risposta non valida dal server a monte. Spesso l'applicazione dietro il proxy è andata in crash o non è in ascolto. RFC 9110
503 Service Unavailable: Il server al momento non può gestire la richiesta, per sovraccarico o manutenzione. L'header Retry-After può indicare quando riprovare. RFC 9110
504 Gateway Timeout: Un gateway o un proxy non ha ricevuto in tempo una risposta dal server a monte. Spesso l'applicazione è troppo lenta o non è raggiungibile. RFC 9110
505 HTTP Version Not Supported: Il server non supporta la versione principale di HTTP usata dalla richiesta. RFC 9110
506 Variant Also Negotiates: Il server è configurato male: la variante scelta dalla negoziazione trasparente del contenuto è a sua volta impostata per negoziare, e si crea un ciclo. RFC 2295
507 Insufficient Storage: Il server non riesce a memorizzare ciò che gli serve per completare la richiesta. È definito per WebDAV. RFC 4918
508 Loop Detected: Il server ha interrotto un'operazione WebDAV perché, seguendo i binding, ha trovato un ciclo infinito. RFC 5842
510 Not Extended: Alla richiesta manca un'estensione che il server richiede. La specifica che definiva il codice è ormai storica, e il registro IANA segna il codice come obsoleto. RFC 2774
511 Network Authentication Required: Il client deve autenticarsi per accedere alla rete. Lo invia un captive portal, come la pagina di accesso al Wi-Fi di un hotel, e non il sito richiesto. RFC 6585

Codici non standard

Questi codici non sono nel registro IANA. Ciascuno appartiene a un server o servizio specifico, e il suo significato vale solo lì.

419 Page Expired Non standard: Laravel lo invia quando il token CSRF di un modulo manca o è scaduto. Laravel
444 No Response Non standard: Una configurazione di nginx può restituire 444 per chiudere la connessione senza inviare risposta. Compare nel log di nginx, e il client non riceve nulla. nginx
494 Request Header Too Large Non standard: nginx lo usa internamente quando gli header della richiesta non entrano nei suoi buffer. Al client viene inviata una risposta 400. nginx
495 SSL Certificate Error Non standard: nginx lo usa internamente quando la verifica di un certificato client fallisce. Se la configurazione non lo gestisce, al client viene inviata una risposta 400. nginx
496 SSL Certificate Required Non standard: nginx lo usa internamente quando il client non ha presentato il certificato richiesto dal server. nginx
497 HTTP Request Sent to HTTPS Port Non standard: nginx lo usa internamente quando una richiesta HTTP in chiaro arriva su una porta che si aspetta HTTPS. nginx
499 Client Closed Request Non standard: nginx lo registra quando il client ha chiuso la connessione prima che il server rispondesse. Spesso significa che il timeout del client è più breve del tempo che impiega l'applicazione. nginx
509 Bandwidth Limit Exceeded Non standard: Lo inviano pannelli di controllo per hosting come cPanel quando un sito ha esaurito la banda a disposizione. cPanel
520 Web Server Returned an Unknown Error Non standard: Cloudflare lo invia quando il server di origine ha restituito una risposta vuota, sconosciuta o inattesa. Cloudflare
521 Web Server Is Down Non standard: Cloudflare lo invia quando il server di origine ha rifiutato la sua connessione. Cloudflare
522 Connection Timed Out Non standard: Cloudflare lo invia quando non è riuscito a completare in tempo una connessione TCP verso il server di origine. Cloudflare
523 Origin Is Unreachable Non standard: Cloudflare lo invia quando non è riuscito a raggiungere il server di origine, per esempio per un record DNS sbagliato o un problema di routing. Cloudflare
524 A Timeout Occurred Non standard: Cloudflare si è connesso al server di origine, ma l'origine non ha inviato una risposta HTTP in tempo. Cloudflare
525 SSL Handshake Failed Non standard: Cloudflare lo invia quando l'handshake TLS tra Cloudflare e il server di origine non è andato a buon fine. Cloudflare
526 Invalid SSL Certificate Non standard: Cloudflare lo invia quando non è riuscito a validare il certificato TLS del server di origine. Cloudflare

Informazioni su questo strumento

Come sono organizzati i codici di stato

Ogni risposta HTTP inizia con un codice di stato di tre cifre. La prima cifra indica la classe: 1xx è una risposta provvisoria, 2xx indica un successo, 3xx chiede al client di andare altrove, 4xx dice che l'errore è nella richiesta e 5xx che è nel server. Un client che incontra un codice che non conosce deve trattarlo come il primo codice della sua classe, quindi un 4xx sconosciuto viene gestito come 400.

Il testo dopo il numero, come Not Found, è la reason phrase. È solo una descrizione per le persone: i client devono ignorarla, e HTTP/2 e HTTP/3 non la inviano proprio. I nomi dei codici standard in questo elenco sono quelli del registro IANA, tranne 418, che il registro riporta come (Unused).

Codici che si confondono spesso

401 e 403. 401 significa che il server non sa chi sei, e autenticarti può servire. 403 significa che il server rifiuta la richiesta e che autenticarti di nuovo non cambierà la risposta.

301, 302, 307 e 308. 301 e 308 sono permanenti, 302 e 307 sono temporanei. Con 301 e 302 un client può trasformare un POST in GET quando segue il redirect; 307 e 308 richiedono lo stesso metodo e lo stesso body.

502 e 504. Entrambi arrivano da un proxy o da un load balancer davanti all'applicazione. Con 502 il proxy ha ricevuto qualcosa di non valido o la connessione è fallita; con 504 ha atteso e non ha ricevuto nulla in tempo.

404 e 410. 404 dice che qui non c'è nulla, magari solo per ora. 410 dice che la risorsa è stata rimossa definitivamente.

Da dove viene questo elenco

I codici standard vengono dall'IANA HTTP Status Code Registry. La maggior parte è definita nella RFC 9110, HTTP Semantics, che nel 2022 ha sostituito la RFC 7231. Gli altri vengono da WebDAV e da estensioni minori, e ogni voce indica la sua RFC. Le registrazioni provvisorie che sono ancora Internet-Draft non sono incluse. L'ultimo gruppo raccoglie codici non registrati che però compaiono nei log e nelle pagine di errore di nginx, Cloudflare e altri prodotti.

L'intero elenco fa parte della pagina, quindi si legge anche senza JavaScript. Il campo di ricerca lo filtra nel tuo browser.

Domande

Qual è la differenza tra 401 e 403?

401 Unauthorized significa che la richiesta non ha credenziali valide, e il client può riprovare dopo essersi autenticato. 403 Forbidden significa che il server ha capito la richiesta e la rifiuta: le eventuali credenziali inviate non danno accesso, quindi inviarle di nuovo non serve.

Per un redirect permanente meglio 301 o 308?

Entrambi dicono ai client e ai motori di ricerca che l'URL si è spostato definitivamente. Con 301 un client può trasformare un POST in GET quando segue il redirect, mentre 308 richiede lo stesso metodo e lo stesso body. Per i normali URL di pagina richiesti con GET i due si comportano allo stesso modo.

Qual è la differenza tra 502 e 504?

Entrambi vengono inviati da un proxy, un gateway o un load balancer, non dall'applicazione. 502 Bad Gateway significa che il server a monte ha dato una risposta non valida o ha rifiutato la connessione. 504 Gateway Timeout significa che non ha risposto entro il limite di tempo del proxy.

499 è un vero codice di stato HTTP?

Non è registrato presso IANA. nginx scrive 499 nel suo access log quando il client ha chiuso la connessione prima che la risposta fosse inviata, quindi nessun client lo riceve mai. Altri prodotti usano in modo simile numeri fuori dal registro, come quelli da 520 a 526 di Cloudflare.