6. Response Status Codes (Codici di stato della risposta)

L'elemento status-code è un codice intero a tre cifre che fornisce il risultato del tentativo di comprendere e soddisfare la richiesta.

I codici di stato HTTP sono estensibili. I client HTTP non sono tenuti a comprendere il significato di tutti i codici di stato registrati, sebbene tale comprensione sia ovviamente desiderabile. Tuttavia, un client DEVE comprendere la classe di qualsiasi codice di stato, come indicato dalla prima cifra, e trattare un codice di stato non riconosciuto come equivalente al codice di stato x00 di quella classe, con l'eccezione che un destinatario NON DEVE memorizzare nella cache una risposta con un codice di stato non riconosciuto.

Ad esempio, se un client riceve un codice di stato non riconosciuto di 471, il client può presumere che ci fosse qualcosa di sbagliato nella sua richiesta e trattare la risposta come se avesse ricevuto un codice di stato 400 (Bad Request). Il messaggio di risposta di solito conterrà una rappresentazione che spiega lo stato.

La prima cifra del codice di stato definisce la classe della risposta. Le ultime due cifre non hanno alcun ruolo di categorizzazione. Ci sono cinque valori per la prima cifra:

• 1xx (Informational / Informativo): La richiesta è stata ricevuta, elaborazione in corso
• 2xx (Successful / Riuscito): La richiesta è stata ricevuta, compresa e accettata con successo
• 3xx (Redirection / Reindirizzamento): È necessaria un'ulteriore azione per completare la richiesta
• 4xx (Client Error / Errore del client): La richiesta contiene sintassi errata o non può essere soddisfatta
• 5xx (Server Error / Errore del server): Il server non è riuscito a soddisfare una richiesta apparentemente valida

6.1. Overview of Status Codes (Panoramica dei codici di stato)

I codici di stato elencati di seguito sono definiti in questa specifica. Le frasi di ragione elencate qui sono solo raccomandazioni -- possono essere sostituite da equivalenti locali senza influenzare il protocollo.

Le risposte con codici di stato definiti come memorizzabili nella cache per impostazione predefinita (ad esempio, 200, 203, 204, 206, 300, 301, 404, 405, 410, 414 e 501 in questa specifica) possono essere riutilizzate da una cache con scadenza euristica a meno che non sia indicato diversamente dalla definizione del metodo o dai controlli espliciti della cache [RFC7234]; tutti gli altri codici di stato non sono memorizzabili nella cache per impostazione predefinita.

Codice	Frase di ragione	Definito in
100	Continue	Section 6.2.1
101	Switching Protocols	Section 6.2.2
200	OK	Section 6.3.1
201	Created	Section 6.3.2
202	Accepted	Section 6.3.3
203	Non-Authoritative Information	Section 6.3.4
204	No Content	Section 6.3.5
205	Reset Content	Section 6.3.6
206	Partial Content	RFC7233
300	Multiple Choices	Section 6.4.1
301	Moved Permanently	Section 6.4.2
302	Found	Section 6.4.3
303	See Other	Section 6.4.4
304	Not Modified	RFC7232
305	Use Proxy	Section 6.4.5
306	(Unused)	Section 6.4.6
307	Temporary Redirect	Section 6.4.7
400	Bad Request	Section 6.5.1
401	Unauthorized	RFC7235
402	Payment Required	Section 6.5.2
403	Forbidden	Section 6.5.3
404	Not Found	Section 6.5.4
405	Method Not Allowed	Section 6.5.5
406	Not Acceptable	Section 6.5.6
407	Proxy Authentication Required	RFC7235
408	Request Timeout	Section 6.5.7
409	Conflict	Section 6.5.8
410	Gone	Section 6.5.9
411	Length Required	Section 6.5.10
412	Precondition Failed	RFC7232
413	Payload Too Large	Section 6.5.11
414	URI Too Long	Section 6.5.12
415	Unsupported Media Type	Section 6.5.13
416	Range Not Satisfiable	RFC7233
417	Expectation Failed	Section 6.5.14
426	Upgrade Required	Section 6.5.15
500	Internal Server Error	Section 6.6.1
501	Not Implemented	Section 6.6.2
502	Bad Gateway	Section 6.6.3
503	Service Unavailable	Section 6.6.4
504	Gateway Timeout	Section 6.6.5
505	HTTP Version Not Supported	Section 6.6.6

6.2. Informational 1xx (Informativo 1xx)

La classe 1xx (Informational) di codice di stato indica una risposta provvisoria per comunicare lo stato della connessione o il progresso della richiesta prima di completare l'azione richiesta e inviare una risposta finale. Poiché HTTP/1.0 non ha definito alcun codice di stato 1xx, un server NON DEVE inviare una risposta 1xx a un client HTTP/1.0.

Una risposta 1xx è terminata dalla prima riga vuota dopo la riga di stato (la riga vuota segnala la fine della sezione di intestazione). Poiché una risposta 1xx non può contenere un corpo del messaggio, è sempre terminata dalla prima riga vuota dopo i campi di intestazione.

I client HTTP/1.1 DEVONO essere preparati a ricevere una o più risposte 1xx prima di una risposta finale, anche se il client non si aspetta un messaggio di stato 100 (Continue). Un user agent PUÒ ignorare risposte 1xx impreviste.

Un proxy DEVE inoltrare le risposte 1xx a meno che il proxy stesso non abbia richiesto la generazione della risposta 1xx. Ad esempio, se un proxy aggiunge un campo "Expect: 100-continue" quando inoltra una richiesta, non ha bisogno di inoltrare le risposte 100 (Continue) corrispondenti.

6.2.1. 100 Continue (Continua)

Il codice di stato 100 (Continue) indica che la parte iniziale di una richiesta è stata ricevuta e non è ancora stata rifiutata dal server. Il server intende inviare una risposta finale dopo che la richiesta è stata completamente ricevuta e processata.

Quando la richiesta contiene un campo di intestazione Expect che include un'aspettativa 100-continue, la risposta 100 indica che il server desidera ricevere il corpo del payload della richiesta, come descritto nella Section 5.1.1. Il client dovrebbe continuare a inviare la richiesta e scartare la risposta 100.

Se la richiesta non conteneva un campo di intestazione Expect contenente l'aspettativa 100-continue, il client può semplicemente scartare questa risposta provvisoria.

6.2.2. 101 Switching Protocols (Cambio di protocolli)

Il codice di stato 101 (Switching Protocols) indica che il server comprende ed è disposto a conformarsi alla richiesta del client, tramite il campo di intestazione Upgrade (Section 6.7 di [RFC7230]), per un cambiamento nel protocollo dell'applicazione utilizzato su questa connessione. Il server DEVE generare un campo di intestazione Upgrade nella risposta che indica quale/i protocollo/i sarà/saranno in vigore immediatamente dopo la riga vuota che termina la risposta 101.

Si presume che il server accetterà di cambiare protocolli solo quando è vantaggioso farlo. Ad esempio, passare a una versione più recente di HTTP potrebbe essere vantaggioso rispetto alle versioni precedenti, e passare a un protocollo sincrono in tempo reale potrebbe essere vantaggioso quando si forniscono risorse che utilizzano tali funzionalità.

6.3. Successful 2xx (Riuscito 2xx)

La classe 2xx (Successful) di codice di stato indica che la richiesta del client è stata ricevuta, compresa e accettata con successo.

6.3.1. 200 OK

Il codice di stato 200 (OK) indica che la richiesta ha avuto successo. Il payload inviato in una risposta 200 dipende dal metodo di richiesta. Per i metodi definiti da questa specifica, il significato previsto del payload può essere riassunto come segue:

• GET: una rappresentazione della risorsa target;
• HEAD: la stessa rappresentazione di GET, ma senza i dati di rappresentazione;
• POST: una rappresentazione dello stato di, o dei risultati ottenuti da, l'azione;
• PUT, DELETE: una rappresentazione dello stato dell'azione;
• OPTIONS: una rappresentazione delle opzioni di comunicazione;
• TRACE: una rappresentazione del messaggio di richiesta come ricevuto dal server finale.

A parte le risposte a CONNECT, una risposta 200 ha sempre un payload, sebbene un server di origine POSSA generare un corpo del payload di lunghezza zero. Se non si desidera alcun payload, un server di origine dovrebbe inviare 204 (No Content) invece. Per CONNECT, non è consentito alcun payload perché il risultato riuscito è un tunnel, che inizia immediatamente dopo la sezione di intestazione della risposta 200.

Una risposta 200 è memorizzabile nella cache per impostazione predefinita; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o dai controlli espliciti della cache (vedere Section 4.2.2 di [RFC7234]).

6.3.2. 201 Created (Creato)

Il codice di stato 201 (Created) indica che la richiesta è stata soddisfatta e ha portato alla creazione di una o più nuove risorse. La risorsa principale creata dalla richiesta è identificata da un campo di intestazione Location nella risposta o, se non viene ricevuto alcun campo Location, dall'URI della richiesta effettiva.

Il payload della risposta 201 descrive e collega tipicamente alle risorse create. Vedere Section 7.2 per una discussione del significato e dello scopo dei campi di intestazione del validatore, come ETag e Last-Modified, in una risposta 201.

6.3.3. 202 Accepted (Accettato)

Il codice di stato 202 (Accepted) indica che la richiesta è stata accettata per l'elaborazione, ma l'elaborazione non è stata completata. La richiesta potrebbe o non potrebbe essere eventualmente eseguita, poiché potrebbe essere vietata quando l'elaborazione avviene effettivamente. Non esiste alcuna funzionalità in HTTP per reinviare un codice di stato da un'operazione asincrona.

La risposta 202 è intenzionalmente non impegnativa. Il suo scopo è consentire a un server di accettare una richiesta per qualche altro processo (forse un processo orientato ai batch che viene eseguito solo una volta al giorno) senza richiedere che la connessione dell'user agent al server persista fino al completamento del processo. La rappresentazione inviata con questa risposta dovrebbe descrivere lo stato corrente della richiesta e puntare a (o incorporare) un monitor di stato che può fornire all'utente una stima di quando la richiesta sarà soddisfatta.

6.3.4. 203 Non-Authoritative Information (Informazioni non autorevoli)

Il codice di stato 203 (Non-Authoritative Information) indica che la richiesta ha avuto successo ma il payload incluso è stato modificato rispetto a quello della risposta 200 (OK) del server di origine da un proxy di trasformazione (Section 5.7.2 di [RFC7230]). Questo codice di stato consente al proxy di notificare ai destinatari quando è stata applicata una trasformazione, poiché tale conoscenza potrebbe influire sulle decisioni successive riguardanti il contenuto. Ad esempio, le future richieste di validazione della cache per il contenuto potrebbero essere applicabili solo lungo lo stesso percorso di richiesta (attraverso gli stessi proxy).

La risposta 203 è simile al codice Warning di 214 Transformation Applied (Section 5.5 di [RFC7234]), che ha il vantaggio di essere applicabile alle risposte con qualsiasi codice di stato.

Una risposta 203 è memorizzabile nella cache per impostazione predefinita; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o dai controlli espliciti della cache (vedere Section 4.2.2 di [RFC7234]).

6.3.5. 204 No Content (Nessun contenuto)

Il codice di stato 204 (No Content) indica che il server ha soddisfatto con successo la richiesta e che non c'è contenuto aggiuntivo da inviare nel corpo del payload della risposta. I metadati nei campi di intestazione della risposta si riferiscono alla risorsa target e alla sua rappresentazione selezionata dopo l'applicazione dell'azione richiesta.

Ad esempio, se un codice di stato 204 viene ricevuto in risposta a una richiesta PUT e la risposta contiene un campo di intestazione ETag, allora il PUT ha avuto successo e il valore del campo ETag contiene l'entity-tag per la nuova rappresentazione di quella risorsa target.

La risposta 204 consente a un server di indicare che l'azione è stata applicata con successo alla risorsa target, pur implicando che l'user agent non ha bisogno di allontanarsi dalla sua attuale "vista documento" (se presente). Il server presume che l'user agent fornirà una qualche indicazione del successo al suo utente, in conformità con la propria interfaccia, e applicherà eventuali metadati nuovi o aggiornati nella risposta alla sua rappresentazione attiva.

Ad esempio, un codice di stato 204 è comunemente utilizzato con interfacce di modifica dei documenti corrispondenti a un'azione "salva", in modo che il documento in fase di salvataggio rimanga disponibile per l'utente per la modifica. È anche frequentemente utilizzato con interfacce che si aspettano che i trasferimenti di dati automatizzati siano prevalenti, come all'interno di sistemi di controllo delle versioni distribuite.

Una risposta 204 è terminata dalla prima riga vuota dopo i campi di intestazione perché non può contenere un corpo del messaggio.

Una risposta 204 è memorizzabile nella cache per impostazione predefinita; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o dai controlli espliciti della cache (vedere Section 4.2.2 di [RFC7234]).

6.3.6. 205 Reset Content (Reimposta contenuto)

Il codice di stato 205 (Reset Content) indica che il server ha soddisfatto la richiesta e desidera che l'user agent reimposti la "vista documento", che ha causato l'invio della richiesta, al suo stato originale come ricevuto dal server di origine.

Questa risposta è destinata a supportare un caso d'uso comune di inserimento dati in cui l'utente riceve contenuto che supporta l'inserimento dati (un modulo, blocco note, tela, ecc.), inserisce o manipola dati in quello spazio, fa sì che i dati inseriti vengano inviati in una richiesta, e quindi il meccanismo di inserimento dati viene reimpostato per l'inserimento successivo in modo che l'utente possa facilmente avviare un'altra azione di input.

Poiché il codice di stato 205 implica che non verrà fornito contenuto aggiuntivo, un server NON DEVE generare un payload in una risposta 205. In altre parole, un server DEVE fare una delle seguenti cose per una risposta 205: a) indicare un corpo di lunghezza zero per la risposta includendo un campo di intestazione Content-Length con un valore di 0; b) indicare un payload di lunghezza zero per la risposta includendo un campo di intestazione Transfer-Encoding con un valore di chunked e un corpo del messaggio costituito da un singolo chunk di lunghezza zero; o, c) chiudere la connessione immediatamente dopo aver inviato la riga vuota che termina la sezione di intestazione.

6.4. Redirection 3xx (Reindirizzamento 3xx)

La classe 3xx (Redirection) di codice di stato indica che l'user agent deve intraprendere ulteriori azioni per soddisfare la richiesta. Se viene fornito un campo di intestazione Location (Section 7.1.2), l'user agent PUÒ reindirizzare automaticamente la sua richiesta all'URI referenziato dal valore del campo Location, anche se il codice di stato specifico non è compreso. Il reindirizzamento automatico deve essere effettuato con cautela per i metodi non noti come sicuri, come definito nella Section 4.2.1, poiché l'utente potrebbe non desiderare reindirizzare una richiesta non sicura.

Esistono diversi tipi di reindirizzamenti:

1. Reindirizzamenti che indicano che la risorsa potrebbe essere disponibile presso un URI diverso, come fornito dal campo Location, come nei codici di stato 301 (Moved Permanently), 302 (Found) e 307 (Temporary Redirect).

2. Reindirizzamento che offre una scelta di risorse corrispondenti, ciascuna in grado di rappresentare il target di richiesta originale, come nel codice di stato 300 (Multiple Choices).

3. Reindirizzamento a una risorsa diversa, identificata dal campo Location, che può rappresentare una risposta indiretta alla richiesta, come nel codice di stato 303 (See Other).

4. Reindirizzamento a un risultato precedentemente memorizzato nella cache, come nel codice di stato 304 (Not Modified).

Nota: In HTTP/1.0, i codici di stato 301 (Moved Permanently) e 302 (Found) sono stati definiti per il primo tipo di reindirizzamento ([RFC1945], Section 9.3). I primi user agent si sono divisi sul fatto che il metodo applicato al target di reindirizzamento sarebbe stato lo stesso della richiesta originale o sarebbe stato riscritto come GET. Sebbene HTTP abbia originariamente definito le prime semantiche per 301 e 302 (per corrispondere alla sua implementazione originale al CERN), e abbia definito 303 (See Other) per corrispondere alle ultime semantiche, la pratica prevalente è gradualmente converguta verso le ultime semantiche anche per 301 e 302. La prima revisione di HTTP/1.1 ha aggiunto 307 (Temporary Redirect) per indicare le prime semantiche senza essere influenzata da pratiche divergenti. Più di 10 anni dopo, la maggior parte degli user agent riscrive ancora il metodo per 301 e 302; pertanto, questa specifica rende tale comportamento conforme quando la richiesta originale è POST.

Un client DOVREBBE rilevare e intervenire in reindirizzamenti ciclici (cioè, loop di reindirizzamento "infiniti").

Nota: Una versione precedente di questa specifica raccomandava un massimo di cinque reindirizzamenti ([RFC2068], Section 10.3). Gli sviluppatori di contenuti devono essere consapevoli che alcuni client potrebbero implementare tale limitazione fissa.

6.4.1. 300 Multiple Choices (Scelte multiple)

Il codice di stato 300 (Multiple Choices) indica che la risorsa target ha più di una rappresentazione, ciascuna con il proprio identificatore più specifico, e vengono fornite informazioni sulle alternative in modo che l'utente (o l'user agent) possa selezionare una rappresentazione preferita reindirizzando la sua richiesta a uno o più di quegli identificatori. In altre parole, il server desidera che l'user agent si impegni in una negoziazione reattiva per selezionare la/e rappresentazione/i più appropriata/e per le sue esigenze (Section 3.4.2).

Se il server ha una scelta preferita, il server DOVREBBE generare un campo di intestazione Location contenente un riferimento URI della scelta preferita. L'user agent PUÒ utilizzare il valore del campo Location per il reindirizzamento automatico.

Per metodi di richiesta diversi da HEAD, il server DOVREBBE generare un payload nella risposta 300 contenente un elenco di metadati di rappresentazione e riferimento/i URI da cui l'utente o l'user agent può scegliere quello più preferito. L'user agent PUÒ effettuare una selezione da quell'elenco automaticamente se comprende il tipo di media fornito. Un formato specifico per la selezione automatica non è definito da questa specifica perché HTTP cerca di rimanere ortogonale alla definizione dei suoi payload. In pratica, la rappresentazione viene fornita in un formato facilmente analizzabile ritenuto accettabile per l'user agent, come determinato da una progettazione condivisa o dalla negoziazione del contenuto, o in un formato ipertestuale comunemente accettato.

Una risposta 300 è memorizzabile nella cache per impostazione predefinita; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o dai controlli espliciti della cache (vedere Section 4.2.2 di [RFC7234]).

Nota: La proposta originale per il codice di stato 300 definiva il campo di intestazione URI come fornente un elenco di rappresentazioni alternative, in modo che fosse utilizzabile per risposte 200, 300 e 406 e venisse trasferito nelle risposte al metodo HEAD. Tuttavia, la mancanza di implementazione e il disaccordo sulla sintassi hanno portato alla rimozione sia di URI che di Alternates (una proposta successiva) da questa specifica. È possibile comunicare l'elenco utilizzando un insieme di campi di intestazione Link [RFC5988], ciascuno con una relazione di "alternate", sebbene l'implementazione sia un problema di uovo e gallina.

6.4.2. 301 Moved Permanently (Spostato permanentemente)

Il codice di stato 301 (Moved Permanently) indica che alla risorsa target è stato assegnato un nuovo URI permanente e qualsiasi riferimento futuro a questa risorsa dovrebbe utilizzare uno degli URI inclusi. I client con capacità di modifica dei link dovrebbero automaticamente ricollegare i riferimenti all'URI della richiesta effettiva a uno o più dei nuovi riferimenti inviati dal server, quando possibile.

Il server DOVREBBE generare un campo di intestazione Location nella risposta contenente un riferimento URI preferito per il nuovo URI permanente. L'user agent PUÒ utilizzare il valore del campo Location per il reindirizzamento automatico. Il payload della risposta del server di solito contiene una breve nota ipertestuale con un collegamento ipertestuale ai nuovi URI.

Nota: Per ragioni storiche, un user agent PUÒ cambiare il metodo di richiesta da POST a GET per la richiesta successiva. Se questo comportamento non è desiderato, il codice di stato 307 (Temporary Redirect) può essere utilizzato invece.

Una risposta 301 è memorizzabile nella cache per impostazione predefinita; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o dai controlli espliciti della cache (vedere Section 4.2.2 di [RFC7234]).

6.4.3. 302 Found (Trovato)

Il codice di stato 302 (Found) indica che la risorsa target risiede temporaneamente sotto un URI diverso. Poiché il reindirizzamento potrebbe essere modificato in occasioni, il client dovrebbe continuare a utilizzare l'URI della richiesta effettiva per richieste future.

Il server DOVREBBE generare un campo di intestazione Location nella risposta contenente un riferimento URI per l'URI diverso. L'user agent PUÒ utilizzare il valore del campo Location per il reindirizzamento automatico. Il payload della risposta del server di solito contiene una breve nota ipertestuale con un collegamento ipertestuale agli URI diversi.

Nota: Per ragioni storiche, un user agent PUÒ cambiare il metodo di richiesta da POST a GET per la richiesta successiva. Se questo comportamento non è desiderato, il codice di stato 307 (Temporary Redirect) può essere utilizzato invece.

6.4.4. 303 See Other (Vedi altro)

Il codice di stato 303 (See Other) indica che il server sta reindirizzando l'user agent a una risorsa diversa, come indicato da un URI nel campo di intestazione Location, che è destinato a fornire una risposta indiretta alla richiesta originale. Un user agent può eseguire una richiesta di recupero mirata a quell'URI (una richiesta GET o HEAD se si utilizza HTTP), che potrebbe anche essere reindirizzata, e presentare il risultato finale come risposta alla richiesta originale. Si noti che il nuovo URI nel campo di intestazione Location non è considerato equivalente all'URI della richiesta effettiva.

Questo codice di stato è applicabile a qualsiasi metodo HTTP. Viene utilizzato principalmente per consentire all'output di un'azione POST di reindirizzare l'user agent a una risorsa selezionata, poiché ciò fornisce le informazioni corrispondenti alla risposta POST in una forma che può essere identificata, memorizzata nei preferiti e memorizzata nella cache separatamente, indipendentemente dalla richiesta originale.

Una risposta 303 a una richiesta GET indica che il server di origine non ha una rappresentazione della risorsa target che può essere trasferita dal server tramite HTTP. Tuttavia, il valore del campo Location fa riferimento a una risorsa che è descrittiva della risorsa target, in modo che effettuare una richiesta di recupero su quell'altra risorsa potrebbe risultare in una rappresentazione utile ai destinatari senza implicare che rappresenti la risorsa target originale. Si noti che le risposte alle domande su cosa può essere rappresentato, quali rappresentazioni sono adeguate e cosa potrebbe essere una descrizione utile sono al di fuori dell'ambito di HTTP.

Tranne che per le risposte a una richiesta HEAD, la rappresentazione di una risposta 303 dovrebbe contenere una breve nota ipertestuale con un collegamento ipertestuale allo stesso riferimento URI fornito nel campo di intestazione Location.

6.4.5. 305 Use Proxy (Usa proxy)

Il codice di stato 305 (Use Proxy) è stato definito in una versione precedente di questa specifica ed è ora deprecato (Appendice B).

6.4.6. 306 (Unused / Inutilizzato)

Il codice di stato 306 è stato definito in una versione precedente di questa specifica, non è più utilizzato e il codice è riservato.

6.4.7. 307 Temporary Redirect (Reindirizzamento temporaneo)

Il codice di stato 307 (Temporary Redirect) indica che la risorsa target risiede temporaneamente sotto un URI diverso e l'user agent NON DEVE cambiare il metodo di richiesta se esegue un reindirizzamento automatico a quell'URI. Poiché il reindirizzamento può cambiare nel tempo, il client dovrebbe continuare a utilizzare l'URI della richiesta effettiva originale per richieste future.

Il server DOVREBBE generare un campo di intestazione Location nella risposta contenente un riferimento URI per l'URI diverso. L'user agent PUÒ utilizzare il valore del campo Location per il reindirizzamento automatico. Il payload della risposta del server di solito contiene una breve nota ipertestuale con un collegamento ipertestuale agli URI diversi.

Nota: Questo codice di stato è simile a 302 (Found), tranne che non consente di cambiare il metodo di richiesta da POST a GET. Questa specifica non definisce una controparte equivalente per 301 (Moved Permanently) ([RFC7538], tuttavia, definisce il codice di stato 308 (Permanent Redirect) per questo scopo).

6.5. Client Error 4xx (Errore del client 4xx)

La classe 4xx (Client Error) di codice di stato indica che il client sembra aver commesso un errore. Tranne quando si risponde a una richiesta HEAD, il server DOVREBBE inviare una rappresentazione contenente una spiegazione della situazione di errore e se si tratta di una condizione temporanea o permanente. Questi codici di stato sono applicabili a qualsiasi metodo di richiesta. Gli user agent DOVREBBERO visualizzare qualsiasi rappresentazione inclusa all'utente.

6.5.1. 400 Bad Request (Richiesta errata)

Il codice di stato 400 (Bad Request) indica che il server non può o non vuole elaborare la richiesta a causa di qualcosa che è percepito come un errore del client (ad esempio, sintassi della richiesta errata, framing del messaggio di richiesta non valido o routing della richiesta ingannevole).

6.5.2. 402 Payment Required (Pagamento richiesto)

Il codice di stato 402 (Payment Required) è riservato per uso futuro.

6.5.3. 403 Forbidden (Proibito)

Il codice di stato 403 (Forbidden) indica che il server ha compreso la richiesta ma rifiuta di autorizzarla. Un server che desidera rendere pubblico il motivo per cui la richiesta è stata proibita può descrivere tale motivo nel payload della risposta (se presente).

Se le credenziali di autenticazione sono state fornite nella richiesta, il server le considera insufficienti per concedere l'accesso. Il client NON DOVREBBE ripetere automaticamente la richiesta con le stesse credenziali. Il client PUÒ ripetere la richiesta con credenziali nuove o diverse. Tuttavia, una richiesta potrebbe essere proibita per motivi non correlati alle credenziali.

Un server di origine che desidera "nascondere" l'esistenza corrente di una risorsa target proibita PUÒ invece rispondere con un codice di stato di 404 (Not Found).

6.5.4. 404 Not Found (Non trovato)

Il codice di stato 404 (Not Found) indica che il server di origine non ha trovato una rappresentazione corrente per la risorsa target o non è disposto a divulgare che ne esiste una. Un codice di stato 404 non indica se questa mancanza di rappresentazione è temporanea o permanente; il codice di stato 410 (Gone) è preferito rispetto a 404 se il server di origine sa, presumibilmente attraverso alcuni mezzi configurabili, che la condizione è probabilmente permanente.

Una risposta 404 è memorizzabile nella cache per impostazione predefinita; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o dai controlli espliciti della cache (vedere Section 4.2.2 di [RFC7234]).

6.5.5. 405 Method Not Allowed (Metodo non consentito)

Il codice di stato 405 (Method Not Allowed) indica che il metodo ricevuto nella riga di richiesta è conosciuto dal server di origine ma non è supportato dalla risorsa target. Il server di origine DEVE generare un campo di intestazione Allow in una risposta 405 contenente un elenco dei metodi attualmente supportati dalla risorsa target.

Una risposta 405 è memorizzabile nella cache per impostazione predefinita; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o dai controlli espliciti della cache (vedere Section 4.2.2 di [RFC7234]).

6.5.6. 406 Not Acceptable (Non accettabile)

Il codice di stato 406 (Not Acceptable) indica che la risorsa target non ha una rappresentazione corrente che sarebbe accettabile per l'user agent, secondo i campi di intestazione di negoziazione proattiva ricevuti nella richiesta (Section 5.3), e il server non è disposto a fornire una rappresentazione predefinita.

Il server DOVREBBE generare un payload contenente un elenco di caratteristiche di rappresentazione disponibili e identificatori di risorse corrispondenti da cui l'utente o l'user agent può scegliere quello più appropriato. Un user agent PUÒ selezionare automaticamente la scelta più appropriata da quell'elenco. Tuttavia, questa specifica non definisce alcuno standard per tale selezione automatica, come descritto nella Section 6.4.1.

6.5.7. 408 Request Timeout (Timeout della richiesta)

Il codice di stato 408 (Request Timeout) indica che il server non ha ricevuto un messaggio di richiesta completo entro il tempo che era preparato ad attendere. Un server DOVREBBE inviare l'opzione di connessione "close" (Section 6.1 di [RFC7230]) nella risposta, poiché 408 implica che il server ha deciso di chiudere la connessione piuttosto che continuare ad attendere. Se il client ha una richiesta in sospeso in transito, il client PUÒ ripetere quella richiesta su una nuova connessione.

6.5.8. 409 Conflict (Conflitto)

Il codice di stato 409 (Conflict) indica che la richiesta non poteva essere completata a causa di un conflitto con lo stato corrente della risorsa target. Questo codice viene utilizzato in situazioni in cui l'utente potrebbe essere in grado di risolvere il conflitto e reinviare la richiesta. Il server DOVREBBE generare un payload che include informazioni sufficienti affinché un utente riconosca la fonte del conflitto.

I conflitti sono più probabili che si verifichino in risposta a una richiesta PUT. Ad esempio, se il versionamento è in uso e la rappresentazione in fase di PUT include modifiche a una risorsa che sono in conflitto con quelle apportate da una richiesta precedente (di terze parti), il server di origine potrebbe utilizzare una risposta 409 per indicare che non può completare la richiesta. In questo caso, la rappresentazione della risposta probabilmente conterrebbe informazioni utili per unire le differenze basate sulla cronologia delle revisioni.

6.5.9. 410 Gone (Andato via)

Il codice di stato 410 (Gone) indica che l'accesso alla risorsa target non è più disponibile sul server di origine e che questa condizione è probabilmente permanente. Se il server di origine non sa, o non ha la possibilità di determinare, se la condizione è permanente o meno, dovrebbe essere utilizzato invece il codice di stato 404 (Not Found).

La risposta 410 è principalmente destinata ad assistere il compito di manutenzione web notificando al destinatario che la risorsa è intenzionalmente non disponibile e che i proprietari del server desiderano che i collegamenti remoti a quella risorsa vengano rimossi. Tale evento è comune per servizi promozionali a tempo limitato e per risorse appartenenti a individui non più associati al sito del server di origine. Non è necessario contrassegnare tutte le risorse permanentemente non disponibili come "gone" o mantenere il contrassegno per qualsiasi periodo di tempo -- questo è lasciato alla discrezione del proprietario del server.

Una risposta 410 è memorizzabile nella cache per impostazione predefinita; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o dai controlli espliciti della cache (vedere Section 4.2.2 di [RFC7234]).

6.5.10. 411 Length Required (Lunghezza richiesta)

Il codice di stato 411 (Length Required) indica che il server rifiuta di accettare la richiesta senza un Content-Length definito (Section 3.3.2 di [RFC7230]). Il client PUÒ ripetere la richiesta se aggiunge un campo di intestazione Content-Length valido contenente la lunghezza del corpo del messaggio nel messaggio di richiesta.

6.5.11. 413 Payload Too Large (Payload troppo grande)

Il codice di stato 413 (Payload Too Large) indica che il server rifiuta di elaborare una richiesta perché il payload della richiesta è più grande di quanto il server sia disposto o in grado di elaborare. Il server PUÒ chiudere la connessione per impedire al client di continuare la richiesta.

Se la condizione è temporanea, il server DOVREBBE generare un campo di intestazione Retry-After per indicare che è temporanea e dopo quale tempo il client PUÒ riprovare.

6.5.12. 414 URI Too Long (URI troppo lungo)

Il codice di stato 414 (URI Too Long) indica che il server rifiuta di servire la richiesta perché il target della richiesta (Section 5.3 di [RFC7230]) è più lungo di quanto il server sia disposto a interpretare. Questa condizione rara è probabile che si verifichi solo quando un client ha convertito impropriamente una richiesta POST in una richiesta GET con informazioni di query lunghe, quando il client è disceso in un "buco nero" di reindirizzamento (ad esempio, un prefisso URI reindirizzato che punta a un suffisso di se stesso), o quando il server è sotto attacco da parte di un client che tenta di sfruttare falle di sicurezza.

Una risposta 414 è memorizzabile nella cache per impostazione predefinita; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o dai controlli espliciti della cache (vedere Section 4.2.2 di [RFC7234]).

6.5.13. 415 Unsupported Media Type (Tipo di media non supportato)

Il codice di stato 415 (Unsupported Media Type) indica che il server di origine rifiuta di servire la richiesta perché il payload è in un formato non supportato da questo metodo sulla risorsa target. Il problema del formato potrebbe essere dovuto al Content-Type o Content-Encoding indicato dalla richiesta, o come risultato dell'ispezione diretta dei dati.

6.5.14. 417 Expectation Failed (Aspettativa fallita)

Il codice di stato 417 (Expectation Failed) indica che l'aspettativa fornita nel campo di intestazione Expect della richiesta (Section 5.1.1) non poteva essere soddisfatta da almeno uno dei server in ingresso.

6.5.15. 426 Upgrade Required (Aggiornamento richiesto)

Il codice di stato 426 (Upgrade Required) indica che il server rifiuta di eseguire la richiesta utilizzando il protocollo corrente ma potrebbe essere disposto a farlo dopo che il client è passato a un protocollo diverso. Il server DEVE inviare un campo di intestazione Upgrade in una risposta 426 per indicare il/i protocollo/i richiesto/i (Section 6.7 di [RFC7230]).

Esempio:

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

This service requires use of the HTTP/3.0 protocol.

6.6. Server Error 5xx (Errore del server 5xx)

La classe 5xx (Server Error) di codice di stato indica che il server è consapevole di aver commesso un errore o è incapace di eseguire il metodo richiesto. Tranne quando si risponde a una richiesta HEAD, il server DOVREBBE inviare una rappresentazione contenente una spiegazione della situazione di errore e se si tratta di una condizione temporanea o permanente. Un user agent DOVREBBE visualizzare qualsiasi rappresentazione inclusa all'utente. Questi codici di stato sono applicabili a qualsiasi metodo di richiesta.

6.6.1. 500 Internal Server Error (Errore interno del server)

Il codice di stato 500 (Internal Server Error) indica che il server ha riscontrato una condizione imprevista che gli ha impedito di soddisfare la richiesta.

6.6.2. 501 Not Implemented (Non implementato)

Il codice di stato 501 (Not Implemented) indica che il server non supporta la funzionalità richiesta per soddisfare la richiesta. Questa è la risposta appropriata quando il server non riconosce il metodo di richiesta e non è in grado di supportarlo per qualsiasi risorsa.

Una risposta 501 è memorizzabile nella cache per impostazione predefinita; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o dai controlli espliciti della cache (vedere Section 4.2.2 di [RFC7234]).

6.6.3. 502 Bad Gateway (Gateway errato)

Il codice di stato 502 (Bad Gateway) indica che il server, mentre fungeva da gateway o proxy, ha ricevuto una risposta non valida da un server in ingresso a cui ha avuto accesso nel tentativo di soddisfare la richiesta.

6.6.4. 503 Service Unavailable (Servizio non disponibile)

Il codice di stato 503 (Service Unavailable) indica che il server attualmente non è in grado di gestire la richiesta a causa di un sovraccarico temporaneo o di una manutenzione pianificata, che sarà probabilmente alleviato dopo un certo ritardo. Il server PUÒ inviare un campo di intestazione Retry-After (Section 7.1.3) per suggerire un tempo appropriato che il client dovrebbe attendere prima di riprovare la richiesta.

Nota: L'esistenza del codice di stato 503 non implica che un server debba utilizzarlo quando diventa sovraccarico. Alcuni server potrebbero semplicemente rifiutare la connessione.

6.6.5. 504 Gateway Timeout (Timeout del gateway)

Il codice di stato 504 (Gateway Timeout) indica che il server, mentre fungeva da gateway o proxy, non ha ricevuto una risposta tempestiva da un server upstream a cui doveva accedere per completare la richiesta.

6.6.6. 505 HTTP Version Not Supported (Versione HTTP non supportata)

Il codice di stato 505 (HTTP Version Not Supported) indica che il server non supporta, o rifiuta di supportare, la versione maggiore di HTTP che è stata utilizzata nel messaggio di richiesta. Il server indica che non è in grado o non è disposto a completare la richiesta utilizzando la stessa versione maggiore del client, come descritto nella Section 2.6 di [RFC7230], se non con questo messaggio di errore. Il server DOVREBBE generare una rappresentazione contenente una spiegazione del motivo per cui quella versione non è supportata e quali altri protocolli sono supportati da quel server.

---