15. Status Codes (Codici di stato)

Il codice di stato di una risposta è un codice intero a tre cifre che descrive il risultato della richiesta e la semantica della risposta, incluso se la richiesta ha avuto successo e quale contenuto è incluso (se presente). Tutti i codici di stato validi sono compresi nell'intervallo da 100 a 599 inclusi.

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

1xx (Informational): La richiesta è stata ricevuta, elaborazione in corso
2xx (Successful): La richiesta è stata ricevuta, compresa e accettata con successo
3xx (Redirection): Ulteriori azioni devono essere intraprese per completare la richiesta
4xx (Client Error): La richiesta contiene sintassi errata o non può essere soddisfatta
5xx (Server Error): Il server non è riuscito a soddisfare una richiesta apparentemente valida

I codici di stato HTTP sono estensibili. Un client non è tenuto 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.

Ad esempio, se un client riceve un codice di stato 471 non riconosciuto, può vedere dalla prima cifra che c'era qualcosa di sbagliato con la sua richiesta e trattare la risposta come se avesse ricevuto un codice di stato 400 (Bad Request). Il messaggio di risposta conterrà solitamente una rappresentazione che spiega lo stato.

I valori al di fuori dell'intervallo 100..599 sono non validi. Le implementazioni utilizzano spesso valori interi a tre cifre al di fuori di tale intervallo (cioè 600..999) per la comunicazione interna di stato non HTTP (ad esempio, errori di libreria). Un client che riceve una risposta con un codice di stato non valido DOVREBBE elaborare la risposta come se avesse un codice di stato 5xx (Server Error).

Una singola richiesta può avere più risposte associate: zero o più risposte "intermedie" (non finali) con codici di stato nell'intervallo "informational" (1xx), seguite da esattamente una risposta "finale" con un codice di stato in uno degli altri intervalli.

15.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 o omesse del tutto senza influenzare il protocollo.

Le risposte con codici di stato definiti come euristicamente memorizzabili nella cache (ad esempio, 200, 203, 204, 206, 300, 301, 308, 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 da controlli di cache espliciti [CACHING]; tutti gli altri codici di stato non sono euristicamente memorizzabili nella cache.

Codici di stato aggiuntivi, al di fuori dell'ambito di questa specifica, sono stati specificati per l'uso in HTTP. Tutti questi codici di stato dovrebbero essere registrati nel "Hypertext Transfer Protocol (HTTP) Status Code Registry", come descritto nella Sezione 16.2.

15.2. Informational 1xx

La classe 1xx (Informational) di codici di stato indica una risposta intermedia per comunicare lo stato della connessione o l'avanzamento 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 fine della sezione header; non può contenere contenuto o trailer.

Un client DEVE essere in grado di analizzare una o più risposte 1xx ricevute prima di una risposta finale, anche se il client non ne prevede una. Un user agent PUÒ ignorare risposte 1xx inattese.

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 header "Expect: 100-continue" quando inoltra una richiesta, allora non è necessario che inoltri la risposta 100 (Continue) corrispondente.

15.2.1. 100 Continue

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 agita.

Quando la richiesta contiene un campo header Expect che include un'aspettativa 100-continue, la risposta 100 indica che il server desidera ricevere il contenuto della richiesta, come descritto nella Sezione 10.1.1. Il client dovrebbe continuare a inviare la richiesta e scartare la risposta 100.

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

15.2.2. 101 Switching Protocols

Il codice di stato 101 (Switching Protocols) indica che il server comprende ed è disposto a conformarsi alla richiesta del client, tramite il campo header Upgrade (Sezione 7.8), per un cambio nel protocollo applicativo utilizzato su questa connessione. Il server DEVE generare un campo header Upgrade nella risposta che indica quale/i protocollo/i sarà/saranno in vigore dopo questa risposta.

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 più vecchie, e passare a un protocollo sincrono in tempo reale potrebbe essere vantaggioso quando si forniscono risorse che utilizzano tali funzionalità.

15.3. Successful 2xx

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

15.3.1. 200 OK

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

Request Method	Response content is a representation of:
GET	the target resource
HEAD	the target resource, like GET, but without
	transferring the representation data
POST	the status of, or results obtained from,
	the action
PUT, DELETE	the status of the action
OPTIONS	communication options for the target
	resource
TRACE	the request message as received by the
	server returning the trace

Tabella 6

Fatta eccezione per le risposte a CONNECT, ci si aspetta che una risposta 200 contenga contenuto del messaggio a meno che il framing del messaggio non indichi esplicitamente che il contenuto ha lunghezza zero. Se qualche aspetto della richiesta indica una preferenza per nessun contenuto in caso di successo, il server di origine dovrebbe invece inviare una risposta 204 (No Content). Per CONNECT, non c'è contenuto perché il risultato positivo è un tunnel, che inizia immediatamente dopo la sezione header della risposta 200.

Una risposta 200 è euristicamente memorizzabile nella cache; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o da controlli di cache espliciti (vedere Sezione 4.2.2 di [CACHING]).

Nelle risposte 200 a GET o HEAD, un server di origine DOVREBBE inviare tutti i campi validatore disponibili (Sezione 8.8) per la rappresentazione selezionata, con preferenza sia per un tag di entità forte che per una data Last-Modified.

Nelle risposte 200 ai metodi di cambio di stato, tutti i campi validatore (Sezione 8.8) inviati nella risposta trasmettono i validatori attuali per la nuova rappresentazione formata come risultato dell'applicazione riuscita della semantica della richiesta. Si noti che il metodo PUT (Sezione 9.3.4) ha requisiti aggiuntivi che potrebbero precludere l'invio di tali validatori.

15.3.2. 201 Created

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 primaria creata dalla richiesta è identificata da un campo header Location nella risposta o, se non viene ricevuto alcun campo header Location, dall'URI di destinazione.

Il contenuto della risposta 201 descrive tipicamente e collega alle risorse create. Tutti i campi validatore (Sezione 8.8) inviati nella risposta trasmettono i validatori attuali per una nuova rappresentazione creata dalla richiesta. Si noti che il metodo PUT (Sezione 9.3.4) ha requisiti aggiuntivi che potrebbero precludere l'invio di tali validatori.

15.3.3. 202 Accepted

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 potrebbe non essere eventualmente eseguita, poiché potrebbe essere vietata quando l'elaborazione avviene effettivamente. Non esiste alcun meccanismo in HTTP per rinviare 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 un 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 attuale della richiesta e puntare a (o incorporare) un monitor di stato che può fornire all'utente una stima di quando la richiesta sarà soddisfatta.

15.3.4. 203 Non-Authoritative Information

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

Una risposta 203 è euristicamente memorizzabile nella cache; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o da controlli di cache espliciti (vedere Sezione 4.2.2 di [CACHING]).

15.3.5. 204 No Content

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 contenuto della risposta. I metadati nei campi header della risposta si riferiscono alla risorsa di destinazione 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 ETag, allora il PUT ha avuto successo e il valore del campo ETag contiene il tag di entità per la nuova rappresentazione di quella risorsa di destinazione.

La risposta 204 consente a un server di indicare che l'azione è stata applicata con successo alla risorsa di destinazione, 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 accordo con la propria interfaccia, e applicherà tutti i nuovi metadati o aggiornamenti nella risposta alla sua rappresentazione attiva.

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

Una risposta 204 è terminata dalla fine della sezione header; non può contenere contenuto o trailer.

Una risposta 204 è euristicamente memorizzabile nella cache; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o da controlli di cache espliciti (vedere Sezione 4.2.2 di [CACHING]).

15.3.6. 205 Reset Content

Il codice di stato 205 (Reset Content) indica che il server ha soddisfatto la richiesta e desidera che l'user agent reimporti 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 immissione dati in cui l'utente riceve contenuto che supporta l'immissione dati (un modulo, notepad, canvas, ecc.), inserisce o manipola i dati in quello spazio, causa l'invio dei dati inseriti in una richiesta, e quindi il meccanismo di immissione dati viene reimpostato per la prossima immissione in modo che l'utente possa facilmente avviare un'altra azione di input.

Poiché il codice di stato 205 implica che non verrà fornito alcun contenuto aggiuntivo, un server NON DEVE generare contenuto in una risposta 205.

15.3.7. 206 Partial Content

Il codice di stato 206 (Partial Content) indica che il server sta soddisfacendo con successo una richiesta di intervallo per la risorsa di destinazione trasferendo una o più parti della rappresentazione selezionata.

Un server che supporta richieste di intervallo (Sezione 14) tenterà solitamente di soddisfare tutti gli intervalli richiesti, poiché l'invio di meno dati comporterà probabilmente un'altra richiesta del client per il resto. Tuttavia, un server potrebbe voler inviare solo un sottoinsieme dei dati richiesti per le proprie ragioni, come indisponibilità temporanea, efficienza della cache, bilanciamento del carico, ecc. Poiché una risposta 206 è autodescrittiva, il client può comunque comprendere una risposta che soddisfa solo parzialmente la sua richiesta di intervallo.

Un client DEVE ispezionare i campi Content-Type e Content-Range di una risposta 206 per determinare quali parti sono incluse e se sono necessarie richieste aggiuntive.

Un server che genera una risposta 206 DEVE generare i seguenti campi header, oltre a quelli richiesti nelle sottosezioni seguenti, se il campo sarebbe stato inviato in una risposta 200 (OK) alla stessa richiesta: Date, Cache-Control, ETag, Expires, Content-Location e Vary.

Un campo header Content-Length presente in una risposta 206 indica il numero di ottetti nel contenuto di questo messaggio, che di solito non è la lunghezza completa della rappresentazione selezionata. Ogni campo header Content-Range include informazioni sulla lunghezza completa della rappresentazione selezionata.

Un mittente che genera una risposta 206 a una richiesta con un campo header If-Range NON DOVREBBE generare altri campi header di rappresentazione oltre a quelli richiesti perché il client ha già una risposta precedente contenente quei campi header. Altrimenti, un mittente DEVE generare tutti i campi header di rappresentazione che sarebbero stati inviati in una risposta 200 (OK) alla stessa richiesta.

Una risposta 206 è euristicamente memorizzabile nella cache; cioè, a meno che non sia indicato diversamente da controlli di cache espliciti (vedere Sezione 4.2.2 di [CACHING]).

15.3.7.1. Single Part

Se viene trasferita una singola parte, il server che genera la risposta 206 DEVE generare un campo header Content-Range, che descrive quale intervallo della rappresentazione selezionata è incluso, e un contenuto costituito dall'intervallo. Ad esempio:

HTTP/1.1 206 Partial Content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-Range: bytes 21010-47021/47022 Content-Length: 26012 Content-Type: image/gif

... 26012 bytes of partial image data ...

15.3.7.2. Multiple Parts

Se vengono trasferite più parti, il server che genera la risposta 206 DEVE generare contenuto "multipart/byteranges", come definito nella Sezione 14.6, e un campo header Content-Type contenente il tipo di media "multipart/byteranges" e il suo parametro boundary richiesto. Per evitare confusione con le risposte a parte singola, un server NON DEVE generare un campo header Content-Range nella sezione header HTTP di una risposta multiparte (questo campo verrà invece inviato in ciascuna parte).

Nell'area header di ciascuna parte del corpo nel contenuto multiparte, il server DEVE generare un campo header Content-Range corrispondente all'intervallo incluso in quella parte del corpo. Se la rappresentazione selezionata avesse avuto un campo header Content-Type in una risposta 200 (OK), il server DOVREBBE generare lo stesso campo header Content-Type nell'area header di ciascuna parte del corpo. Ad esempio:

HTTP/1.1 206 Partial Content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-Length: 1741 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES Content-Type: application/pdf Content-Range: bytes 500-999/8000

...the first range... --THIS_STRING_SEPARATES Content-Type: application/pdf Content-Range: bytes 7000-7999/8000

...the second range --THIS_STRING_SEPARATES--

Quando vengono richiesti più intervalli, un server PUÒ unire tutti gli intervalli che si sovrappongono, o che sono separati da uno spazio minore del sovraccarico di invio di più parti, indipendentemente dall'ordine in cui la specifica dell'intervallo corrispondente è apparsa nel campo header Range ricevuto. Poiché il sovraccarico tipico tra ciascuna parte di un "multipart/byteranges" è di circa 80 byte, a seconda del tipo di media della rappresentazione selezionata e della lunghezza del parametro boundary scelto, può essere meno efficiente trasferire molte piccole parti disgiunte che trasferire l'intera rappresentazione selezionata.

Un server NON DEVE generare una risposta multiparte a una richiesta per un singolo intervallo, poiché un client che non richiede più parti potrebbe non supportare risposte multiparty. Tuttavia, un server PUÒ generare una risposta "multipart/byteranges" con una sola parte del corpo se sono stati richiesti più intervalli e solo un intervallo è stato trovato soddisfacibile o è rimasto solo un intervallo dopo l'unione. Un client che non può elaborare una risposta "multipart/byteranges" NON DEVE generare una richiesta che chiede più intervalli.

Un server che genera una risposta multiparte DOVREBBE inviare le parti nello stesso ordine in cui la specifica dell'intervallo corrispondente è apparsa nel campo header Range ricevuto, escludendo quegli intervalli che sono stati ritenuti insoddisfacibili o uniti in altri intervalli. Un client che riceve una risposta multiparte DEVE ispezionare il campo header Content-Range presente in ciascuna parte del corpo per determinare quale intervallo è contenuto in quella parte del corpo; un client non può fare affidamento sulla ricezione degli stessi intervalli che ha richiesto, né dello stesso ordine che ha richiesto.

15.3.7.3. Combining Parts

Una risposta potrebbe trasferire solo un sottointervallo di una rappresentazione se la connessione si è chiusa prematuramente o se la richiesta ha utilizzato una o più specifiche di intervallo. Dopo diversi di questi trasferimenti, un client potrebbe aver ricevuto diversi intervalli della stessa rappresentazione. Questi intervalli possono essere combinati in sicurezza solo se hanno tutti in comune lo stesso validatore forte (Sezione 8.8.1).

Un client che ha ricevuto più risposte parziali a richieste GET su una risorsa di destinazione PUÒ combinare quelle risposte in un intervallo continuo più ampio se condividono lo stesso validatore forte.

Se la risposta più recente è una risposta 200 (OK) incompleta, allora i campi header di quella risposta vengono utilizzati per qualsiasi risposta combinata e sostituiscono quelli delle risposte memorizzate corrispondenti.

Se la risposta più recente è una risposta 206 (Partial Content) e almeno una delle risposte memorizzate corrispondenti è una 200 (OK), allora i campi header della risposta combinata consistono nei campi header della risposta 200 più recente. Se tutte le risposte memorizzate corrispondenti sono risposte 206, allora la risposta memorizzata con i campi header più recenti viene utilizzata come fonte dei campi header per la risposta combinata, tranne che il client DEVE utilizzare altri campi header forniti nella nuova risposta, oltre a Content-Range, per sostituire tutte le istanze del campo header corrispondente nella risposta memorizzata.

Il contenuto della risposta combinata consiste nell'unione degli intervalli di contenuto parziale all'interno della nuova risposta e di tutte le risposte memorizzate corrispondenti. Se l'unione consiste nell'intero intervallo della rappresentazione, allora il client DEVE elaborare la risposta combinata come se fosse una risposta 200 (OK) completa, includendo un campo header Content-Length che riflette la lunghezza completa. Altrimenti, il client DEVE elaborare l'insieme di intervalli continui come uno dei seguenti: una risposta 200 (OK) incompleta se la risposta combinata è un prefisso della rappresentazione, una singola risposta 206 (Partial Content) contenente contenuto "multipart/byteranges", o più risposte 206 (Partial Content), ciascuna con un intervallo continuo indicato da un campo header Content-Range.

15.4. Redirection 3xx

La classe 3xx (Redirection) di codici di stato indica che ulteriori azioni devono essere intraprese dall'user agent per soddisfare la richiesta. Esistono diversi tipi di reindirizzamenti:

Reindirizzamenti che indicano che questa risorsa potrebbe essere disponibile presso un URI diverso, come fornito dal campo header Location, come nei codici di stato 301 (Moved Permanently), 302 (Found), 307 (Temporary Redirect) e 308 (Permanent Redirect).
Reindirizzamento che offre una scelta tra risorse corrispondenti in grado di rappresentare questa risorsa, come nel codice di stato 300 (Multiple Choices).
Reindirizzamento a una risorsa diversa, identificata dal campo header Location, che può rappresentare una risposta indiretta alla richiesta, come nel codice di stato 303 (See Other).
Reindirizzamento a un risultato precedentemente memorizzato, come nel codice di stato 304 (Not Modified).

| Nota: In HTTP/1.0, i codici di stato 301 (Moved Permanently) e 302 | (Found) erano originariamente definiti come preservanti il metodo | ([HTTP/1.0], Sezione 9.3) per corrispondere alla loro implementazione | al CERN; 303 (See Other) è stato definito per un reindirizzamento che | cambiava il suo metodo in GET. Tuttavia, i primi user agent si sono | divisi sul fatto di reindirizzare le richieste POST come POST (secondo | la specifica allora corrente) o come GET (l'alternativa più sicura | quando reindirizzati a un sito diverso). La pratica prevalente è | finalmente convergere sul cambiamento del metodo in GET. 307 (Temporary | Redirect) e 308 (Permanent Redirect) [RFC7538] sono stati aggiunti in | seguito per indicare inequivocabilmente reindirizzamenti che | preservano il metodo, e i codici di stato 301 e 302 sono stati | adattati per consentire che una richiesta POST sia reindirizzata come | GET.

Se viene fornito un campo header Location (Sezione 10.2.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 eseguito con cautela per i metodi non noti per essere sicuri, come definito nella Sezione 9.2.1, poiché l'utente potrebbe non voler reindirizzare una richiesta non sicura.

Quando si segue automaticamente una richiesta reindirizzata, l'user agent DOVREBBE rinviare il messaggio di richiesta originale con le seguenti modifiche:

Sostituire l'URI di destinazione con l'URI referenziato dal valore del campo header Location della risposta di reindirizzamento dopo averlo risolto rispetto all'URI di destinazione della richiesta originale.
Rimuovere i campi header che sono stati generati automaticamente dall'implementazione, sostituendoli con valori aggiornati appropriati alla nuova richiesta. Ciò include:
1. Campi header specifici della connessione (vedere Sezione 7.6.1),
2. Campi header specifici della configurazione proxy del client, inclusi (ma non limitati a) Proxy-Authorization,
3. Campi header specifici dell'origine (se presenti), inclusi (ma non limitati a) Host,
4. Campi header di convalida che sono stati aggiunti dalla cache dell'implementazione (ad esempio, If-None-Match, If-Modified-Since), e
5. Campi header specifici della risorsa, inclusi (ma non limitati a) Referer, Origin, Authorization e Cookie.
Considerare la rimozione dei campi header che non sono stati generati automaticamente dall'implementazione (cioè, quelli presenti nella richiesta perché sono stati aggiunti dal contesto chiamante) dove ci sono implicazioni di sicurezza; ciò include ma non è limitato a Authorization e Cookie.
Modificare il metodo di richiesta secondo la semantica del codice di stato di reindirizzamento, se applicabile.
Se il metodo di richiesta è stato modificato in GET o HEAD, rimuovere i campi header specifici del contenuto, inclusi (ma non limitati a) Content-Encoding, Content-Language, Content-Location, Content-Type, Content-Length, Digest, Last-Modified.

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

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

15.4.1. 300 Multiple Choices

Il codice di stato 300 (Multiple Choices) indica che la risorsa di destinazione 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 tali identificatori. In altre parole, il server desidera che l'user agent si impegni nella negoziazione reattiva per selezionare la rappresentazione o le rappresentazioni più appropriate per le sue esigenze (Sezione 12).

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

Per i metodi di richiesta diversi da HEAD, il server DOVREBBE generare contenuto nella risposta 300 contenente un elenco di metadati di rappresentazione e riferimenti URI da cui l'utente o l'user agent può scegliere quello più preferito. L'user agent PUÒ effettuare una selezione automatica da tale elenco 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 del suo contenuto. In pratica, la rappresentazione viene fornita in un formato facilmente analizzabile ritenuto accettabile per l'user agent, come determinato dalla progettazione condivisa o dalla negoziazione dei contenuti, o in un formato ipertestuale comunemente accettato.

Una risposta 300 è euristicamente memorizzabile nella cache; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o da controlli di cache espliciti (vedere Sezione 4.2.2 di [CACHING]).

| Nota: La proposta originale per il codice di stato 300 definiva il | campo header URI come fornire un elenco di rappresentazioni | alternative, in modo che fosse utilizzabile per le risposte 200, 300 e | 406 e fosse trasferito nelle risposte al metodo HEAD. Tuttavia, la | mancanza di implementazione e il disaccordo sulla sintassi hanno | portato sia URI che Alternates (una proposta successiva) ad essere | abbandonati da questa specifica. È possibile comunicare l'elenco come | valore del campo header Link [RFC8288] i cui membri hanno una | relazione di "alternate", sebbene l'implementazione sia un problema | dell'uovo e della gallina.

15.4.2. 301 Moved Permanently

Il codice di stato 301 (Moved Permanently) indica che alla risorsa di destinazione è stato assegnato un nuovo URI permanente e qualsiasi riferimento futuro a questa risorsa dovrebbe utilizzare uno degli URI allegati. Il server sta suggerendo che un user agent con capacità di modifica dei collegamenti può sostituire permanentemente i riferimenti all'URI di destinazione con uno dei nuovi riferimenti inviati dal server. Tuttavia, questo suggerimento viene generalmente ignorato a meno che l'user agent non stia attivamente modificando i riferimenti (ad esempio, impegnato nella creazione di contenuti), la connessione sia protetta e il server di origine sia un'autorità attendibile per il contenuto in fase di modifica.

Il server DOVREBBE generare un campo header 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 contenuto della risposta del server contiene solitamente 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 308 (Permanent | Redirect) può essere utilizzato al suo posto.

Una risposta 301 è euristicamente memorizzabile nella cache; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o da controlli di cache espliciti (vedere Sezione 4.2.2 di [CACHING]).

15.4.3. 302 Found

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

Il server DOVREBBE generare un campo header 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 contenuto della risposta del server contiene solitamente 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 al suo posto.

15.4.4. 303 See Other

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 header Location, che è destinata a fornire una risposta indiretta alla richiesta originale. Un user agent può eseguire una richiesta di recupero mirando a tale 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 header Location non è considerato equivalente all'URI di destinazione.

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 diversa, poiché ciò fornisce le informazioni corrispondenti alla risposta POST come risorsa che può essere identificata, contrassegnata e memorizzata nella cache separatamente.

Una risposta 303 a una richiesta GET indica che il server di origine non ha una rappresentazione della risorsa di destinazione che può essere trasferita dal server su HTTP. Tuttavia, il valore del campo Location si riferisce a una risorsa che è descrittiva della risorsa di destinazione, in modo che l'esecuzione di una richiesta di recupero su tale altra risorsa potrebbe risultare in una rappresentazione utile per i destinatari senza implicare che rappresenti la risorsa di destinazione 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.

Fatta eccezione 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 header Location.

15.4.5. 304 Not Modified

Il codice di stato 304 (Not Modified) indica che una richiesta GET o HEAD condizionale è stata ricevuta e avrebbe portato a una risposta 200 (OK) se non fosse stato per il fatto che la condizione è stata valutata come falsa. In altre parole, non c'è bisogno che il server trasferisca una rappresentazione della risorsa di destinazione perché la richiesta indica che il client, che ha reso la richiesta condizionale, ha già una rappresentazione valida; il server sta quindi reindirizzando il client a utilizzare quella rappresentazione memorizzata come se fosse il contenuto di una risposta 200 (OK).

Il server che genera una risposta 304 DEVE generare uno qualsiasi dei seguenti campi header che sarebbe stato inviato in una risposta 200 (OK) alla stessa richiesta:

Content-Location, Date, ETag e Vary
Cache-Control ed Expires (vedere [CACHING])

Poiché l'obiettivo di una risposta 304 è minimizzare il trasferimento di informazioni quando il destinatario ha già una o più rappresentazioni memorizzate nella cache, un mittente NON DOVREBBE generare metadati di rappresentazione diversi dai campi elencati sopra a meno che tali metadati non esistano allo scopo di guidare gli aggiornamenti della cache (ad esempio, Last-Modified potrebbe essere utile se la risposta non ha un campo ETag).

I requisiti su una cache che riceve una risposta 304 sono definiti nella Sezione 4.3.4 di [CACHING]. Se la richiesta condizionale proveniva da un client in uscita, come un user agent con la propria cache che invia un GET condizionale a un proxy condiviso, allora il proxy DOVREBBE inoltrare la risposta 304 a quel client.

Una risposta 304 è terminata dalla fine della sezione header; non può contenere contenuto o trailer.

15.4.6. 305 Use Proxy

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

15.4.7. 306 (Unused)

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

15.4.8. 307 Temporary Redirect

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

15.4.9. 308 Permanent Redirect

Il codice di stato 308 (Permanent Redirect) indica che alla risorsa di destinazione è stato assegnato un nuovo URI permanente e qualsiasi riferimento futuro a questa risorsa dovrebbe utilizzare uno degli URI allegati. Il server sta suggerendo che un user agent con capacità di modifica dei collegamenti può sostituire permanentemente i riferimenti all'URI di destinazione con uno dei nuovi riferimenti inviati dal server. Tuttavia, questo suggerimento viene generalmente ignorato a meno che l'user agent non stia attivamente modificando i riferimenti (ad esempio, impegnato nella creazione di contenuti), la connessione sia protetta e il server di origine sia un'autorità attendibile per il contenuto in fase di modifica.

Una risposta 308 è euristicamente memorizzabile nella cache; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o da controlli di cache espliciti (vedere Sezione 4.2.2 di [CACHING]).

| Nota: Questo codice di stato è molto più giovane (giugno 2014) dei | suoi codici fratelli e quindi potrebbe non essere riconosciuto ovunque. | Vedere la Sezione 4 di [RFC7538] per considerazioni sull'implementazione.

15.5. Client Error 4xx

La classe 4xx (Client Error) di codici di stato indica che il client sembra aver commesso un errore. Fatta eccezione per la risposta 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.

15.5.1. 400 Bad Request

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

15.5.2. 401 Unauthorized

Il codice di stato 401 (Unauthorized) indica che la richiesta non è stata applicata perché mancano credenziali di autenticazione valide per la risorsa di destinazione. Il server che genera una risposta 401 DEVE inviare un campo header WWW-Authenticate (Sezione 11.6.1) contenente almeno una sfida applicabile alla risorsa di destinazione.

Se la richiesta includeva credenziali di autenticazione, allora la risposta 401 indica che l'autorizzazione è stata rifiutata per tali credenziali. L'user agent PUÒ ripetere la richiesta con un nuovo o sostituito campo header Authorization (Sezione 11.6.2). Se la risposta 401 contiene la stessa sfida della risposta precedente, e l'user agent ha già tentato l'autenticazione almeno una volta, allora l'user agent DOVREBBE presentare la rappresentazione allegata all'utente, poiché di solito contiene informazioni diagnostiche pertinenti.

15.5.3. 402 Payment Required

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

15.5.4. 403 Forbidden

Il codice di stato 403 (Forbidden) indica che il server ha compreso la richiesta ma rifiuta di soddisfarla. Un server che desidera rendere pubblico perché la richiesta è stata vietata può descrivere tale motivo nel contenuto 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 vietata per motivi non correlati alle credenziali.

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

15.5.5. 404 Not Found

Il codice di stato 404 (Not Found) indica che il server di origine non ha trovato una rappresentazione attuale per la risorsa di destinazione 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 a 404 se il server di origine sa, presumibilmente attraverso qualche mezzo configurabile, che la condizione è probabilmente permanente.

Una risposta 404 è euristicamente memorizzabile nella cache; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o da controlli di cache espliciti (vedere Sezione 4.2.2 di [CACHING]).

15.5.6. 405 Method Not Allowed

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

Una risposta 405 è euristicamente memorizzabile nella cache; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o da controlli di cache espliciti (vedere Sezione 4.2.2 di [CACHING]).

15.5.7. 406 Not Acceptable

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

Il server DOVREBBE generare contenuto contenente un elenco delle caratteristiche di rappresentazione disponibili e degli 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 tale elenco. Tuttavia, questa specifica non definisce alcuno standard per tale selezione automatica, come descritto nella Sezione 15.4.1.

15.5.8. 407 Proxy Authentication Required

Il codice di stato 407 (Proxy Authentication Required) è simile a 401 (Unauthorized), ma indica che il client deve autenticarsi per utilizzare un proxy per questa richiesta. Il proxy DEVE inviare un campo header Proxy-Authenticate (Sezione 11.7.1) contenente una sfida applicabile a quel proxy per la richiesta. Il client PUÒ ripetere la richiesta con un nuovo o sostituito campo header Proxy-Authorization (Sezione 11.7.2).

15.5.9. 408 Request Timeout

Il codice di stato 408 (Request Timeout) indica che il server non ha ricevuto un messaggio di richiesta completo entro il tempo che era disposto ad attendere.

Se il client ha una richiesta in sospeso in transito, PUÒ ripetere quella richiesta. Se la connessione attuale non è utilizzabile (ad esempio, come sarebbe in HTTP/1.1 perché la delimitazione della richiesta è persa), verrà utilizzata una nuova connessione.

15.5.10. 409 Conflict

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

I conflitti sono più probabili in risposta a una richiesta PUT. Ad esempio, se si utilizza il controllo delle versioni e la rappresentazione in corso 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 in base alla cronologia delle revisioni.

15.5.11. 410 Gone

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

La risposta 410 è destinata principalmente 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 tale risorsa vengano rimossi. Tale evento è comune per i servizi promozionali a tempo limitato e per le 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 -- ciò è lasciato alla discrezione del proprietario del server.

Una risposta 410 è euristicamente memorizzabile nella cache; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o da controlli di cache espliciti (vedere Sezione 4.2.2 di [CACHING]).

15.5.12. 411 Length Required

Il codice di stato 411 (Length Required) indica che il server rifiuta di accettare la richiesta senza un Content-Length definito (Sezione 8.6). Il client PUÒ ripetere la richiesta se aggiunge un campo header Content-Length valido contenente la lunghezza del contenuto della richiesta.

15.5.13. 412 Precondition Failed

Il codice di stato 412 (Precondition Failed) indica che una o più condizioni specificate nei campi header della richiesta sono state valutate come false quando testate sul server (Sezione 13). Questo codice di stato della risposta consente al client di inserire precondizioni sullo stato attuale della risorsa (le sue rappresentazioni e metadati attuali) e, quindi, impedire che il metodo di richiesta venga applicato se la risorsa di destinazione è in uno stato inaspettato.

15.5.14. 413 Content Too Large

Il codice di stato 413 (Content Too Large) indica che il server rifiuta di elaborare una richiesta perché il contenuto della richiesta è più grande di quanto il server sia disposto o in grado di elaborare. Il server PUÒ terminare la richiesta, se la versione del protocollo in uso lo consente; altrimenti, il server PUÒ chiudere la connessione.

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

15.5.15. 414 URI Too Long

Il codice di stato 414 (URI Too Long) indica che il server rifiuta di servire la richiesta perché l'URI di destinazione è più lungo di quanto il server sia disposto a interpretare. Questa rara condizione si verifica probabilmente solo quando un client ha convertito in modo errato una richiesta POST in una richiesta GET con informazioni di query lunghe, quando il client è sceso in un loop infinito di reindirizzamento (ad esempio, un prefisso URI reindirizzato che punta a un suffisso di se stesso) o quando il server è sotto attacco da un client che tenta di sfruttare potenziali falle di sicurezza.

Una risposta 414 è euristicamente memorizzabile nella cache; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o da controlli di cache espliciti (vedere Sezione 4.2.2 di [CACHING]).

15.5.16. 415 Unsupported Media Type

Il codice di stato 415 (Unsupported Media Type) indica che il server di origine rifiuta di servire la richiesta perché il contenuto è in un formato non supportato da questo metodo sulla risorsa di destinazione.

Il problema di formato potrebbe essere dovuto al Content-Type o Content-Encoding indicato della richiesta, o come risultato dell'ispezione diretta dei dati.

Se il problema era causato da una codifica di contenuto non supportata, il campo header della risposta Accept-Encoding (Sezione 12.5.3) dovrebbe essere utilizzato per indicare quale/i codifica/e di contenuto sarebbe/ero stata/e accettata/e nella richiesta.

D'altra parte, se la causa era un tipo di media non supportato, il campo header della risposta Accept (Sezione 12.5.1) può essere utilizzato per indicare quali tipi di media sarebbero stati accettati nella richiesta.

15.5.17. 416 Range Not Satisfiable

Il codice di stato 416 (Range Not Satisfiable) indica che l'insieme degli intervalli nel campo header Range della richiesta (Sezione 14.2) è stato rifiutato perché nessuno degli intervalli richiesti è soddisfacibile o perché il client ha richiesto un numero eccessivo di intervalli piccoli o sovrapposti (un potenziale attacco di denial of service).

Ogni unità di intervallo definisce cosa è richiesto affinché i propri insiemi di intervalli siano soddisfacibili. Ad esempio, la Sezione 14.1.2 definisce cosa rende soddisfacibile un insieme di intervalli di byte.

Un server che genera una risposta 416 a una richiesta di intervallo di byte DOVREBBE generare un campo header Content-Range specificando la lunghezza attuale della rappresentazione selezionata (Sezione 14.4).

Ad esempio:

HTTP/1.1 416 Range Not Satisfiable Date: Fri, 20 Jan 2012 15:41:54 GMT Content-Range: bytes */47022

| Nota: Poiché i server sono liberi di ignorare Range, molte | implementazioni risponderanno con l'intera rappresentazione selezionata | in una risposta 200 (OK). Ciò è in parte perché la maggior parte dei | client è preparata a ricevere una 200 (OK) per completare l'attività | (sebbene meno efficiente) e in parte perché i client potrebbero non | smettere di fare una richiesta di intervallo non valida finché non | hanno ricevuto una rappresentazione completa. Pertanto, i client non | possono fare affidamento sulla ricezione di una risposta 416 (Range Not | Satisfiable) anche quando è la più appropriata.

15.5.18. 417 Expectation Failed

Il codice di stato 417 (Expectation Failed) indica che l'aspettativa specificata nel campo header Expect della richiesta (Sezione 10.1.1) non poteva essere soddisfatta da almeno uno dei server in entrata.

15.5.19. 418 (Unused)

[RFC2324] era un RFC del 1° aprile che derideva i vari modi in cui HTTP veniva abusato; un tale abuso era la definizione di un codice di stato 418 specifico dell'applicazione, che è stato distribuito come scherzo abbastanza spesso da rendere il codice inutilizzabile per qualsiasi uso futuro.

Pertanto, il codice di stato 418 è riservato nel registro dei codici di stato HTTP IANA. Ciò indica che il codice di stato non può attualmente essere assegnato ad altre applicazioni. Se circostanze future ne richiedessero l'uso (ad esempio, esaurimento dei codici di stato 4NN), può essere riassegnato a un altro uso.

15.5.20. 421 Misdirected Request

Il codice di stato 421 (Misdirected Request) indica che la richiesta è stata diretta a un server che non è in grado o non è disposto a produrre una risposta autorevole per l'URI di destinazione. Un server di origine (o gateway che agisce per conto del server di origine) invia 421 per rifiutare un URI di destinazione che non corrisponde a un'origine per cui il server è stato configurato (Sezione 4.3.1) o non corrisponde al contesto di connessione su cui è stata ricevuta la richiesta (Sezione 7.4).

Un client che riceve una risposta 421 (Misdirected Request) PUÒ riprovare la richiesta, indipendentemente dal fatto che il metodo di richiesta sia idempotente o meno, su una connessione diversa, come una nuova connessione specifica per l'origine della risorsa di destinazione, o tramite un servizio alternativo [ALTSVC].

Un proxy NON DEVE generare una risposta 421.

15.5.21. 422 Unprocessable Content

Il codice di stato 422 (Unprocessable Content) indica che il server comprende il tipo di contenuto del contenuto della richiesta (quindi un codice di stato 415 (Unsupported Media Type) è inappropriato), e la sintassi del contenuto della richiesta è corretta, ma non è stato in grado di elaborare le istruzioni contenute. Ad esempio, questo codice di stato può essere inviato se un contenuto di richiesta XML contiene istruzioni XML ben formate (cioè, sintatticamente corrette), ma semanticamente erronee.

15.5.22. 426 Upgrade Required

Il codice di stato 426 (Upgrade Required) indica che il server rifiuta di eseguire la richiesta utilizzando il protocollo attuale ma potrebbe essere disposto a farlo dopo che il client passa a un protocollo diverso. Il server DEVE inviare un campo header Upgrade in una risposta 426 per indicare il/i protocollo/i richiesto/i (Sezione 7.8).

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.

15.6. Server Error 5xx

La classe 5xx (Server Error) di codici di stato indica che il server è consapevole di aver commesso un errore o è incapace di eseguire il metodo richiesto. Fatta eccezione per la risposta 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.

15.6.1. 500 Internal Server Error

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

15.6.2. 501 Not Implemented

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 alcuna risorsa.

Una risposta 501 è euristicamente memorizzabile nella cache; cioè, a meno che non sia indicato diversamente dalla definizione del metodo o da controlli di cache espliciti (vedere Sezione 4.2.2 di [CACHING]).

15.6.3. 502 Bad Gateway

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

15.6.4. 503 Service Unavailable

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 programmata, che sarà probabilmente alleviata dopo un certo ritardo. Il server PUÒ inviare un campo header Retry-After (Sezione 10.2.3) per suggerire un periodo di tempo appropriato per cui 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.

15.6.5. 504 Gateway Timeout

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

15.6.6. 505 HTTP Version Not Supported

Il codice di stato 505 (HTTP Version Not Supported) indica che il server non supporta, o rifiuta di supportare, la versione principale di HTTP che è stata utilizzata nel messaggio di richiesta. Il server sta indicando che non è in grado o non è disposto a completare la richiesta utilizzando la stessa versione principale del client, come descritto nella Sezione 2.5, se non con questo messaggio di errore. Il server DOVREBBE generare una rappresentazione per la risposta 505 che descrive perché quella versione non è supportata e quali altri protocolli sono supportati da quel server.