10. Status Code Definitions (Definizioni dei Codici di Stato)
Ciascun codice di stato è descritto di seguito, inclusa una descrizione di quali metodi può seguire e qualsiasi meta-informazione richiesta nella risposta.
10.1 Informational 1xx (Informativo)
Questa classe di codice di stato indica una risposta provvisoria, composta solo dalla Status-Line e header opzionali, e terminata da una riga vuota. Non ci sono header obbligatori per questa classe di codice di stato. Poiché HTTP/1.0 non ha definito alcun codice di stato 1xx, i server non devono (MUST NOT) inviare una risposta 1xx a un client HTTP/1.0, tranne in condizioni sperimentali.
Un client deve (MUST) essere preparato ad accettare una o più risposte di stato 1xx prima della risposta regolare, anche se il client non si aspetta un messaggio di stato 100 (Continue). Gli user agent possono (MAY) ignorare risposte di stato 1xx inaspettate.
Un proxy deve (MUST) inoltrare risposte 1xx, a meno che la connessione tra il proxy e il suo client non sia stata chiusa, o a meno che il proxy stesso 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 la corrispondente risposta 100 (Continue).)
10.1.1 100 Continue
Il client dovrebbe (SHOULD) continuare con la sua richiesta. Questa risposta provvisoria viene utilizzata per informare il client che la parte iniziale della richiesta è stata ricevuta e non è ancora stata rifiutata dal server. Il client dovrebbe (SHOULD) continuare inviando il resto della richiesta o, se la richiesta è già stata completata, ignorare questa risposta. Il server deve (MUST) inviare una risposta finale dopo che la richiesta è stata completata. Vedere la sezione 8.2.3 per una discussione dettagliata sull'uso e la gestione di questo codice di stato.
10.1.2 101 Switching Protocols (Cambio di Protocolli)
Il server comprende e accetta di conformarsi alla richiesta del client, tramite il campo di intestazione Upgrade (sezione 14.42), per un cambio del protocollo di applicazione utilizzato su questa connessione. Il server passerà ai protocolli definiti nel campo di intestazione Upgrade della risposta immediatamente dopo la riga vuota che termina la risposta 101.
Il protocollo dovrebbe (SHOULD) essere cambiato solo quando è vantaggioso farlo. Ad esempio, il passaggio a una versione più recente di HTTP è vantaggioso rispetto alle versioni precedenti, e il passaggio a un protocollo in tempo reale e sincrono potrebbe essere vantaggioso quando si forniscono risorse che utilizzano tali funzionalità.
10.2 Successful 2xx (Successo)
Questa classe di codice di stato indica che la richiesta del client è stata ricevuta, compresa e accettata con successo.
10.2.1 200 OK
La richiesta ha avuto successo. Le informazioni restituite con la risposta dipendono dal metodo utilizzato nella richiesta, ad esempio:
- GET - un'entità corrispondente alla risorsa richiesta viene inviata nella risposta;
- HEAD - i campi di intestazione dell'entità corrispondenti alla risorsa richiesta vengono inviati nella risposta senza alcun corpo del messaggio;
- POST - un'entità che descrive o contiene il risultato dell'azione;
- TRACE - un'entità contenente il messaggio di richiesta come ricevuto dal server finale.
10.2.2 201 Created (Creato)
La richiesta è stata soddisfatta e ha portato alla creazione di una nuova risorsa. La risorsa appena creata può essere referenziata dagli URI restituiti nell'entità della risposta, con l'URI più specifico per la risorsa fornito da un campo di intestazione Location. La risposta dovrebbe (SHOULD) includere un'entità contenente un elenco delle caratteristiche e della posizione della risorsa da cui l'utente o l'user agent può scegliere quella più appropriata. Il formato dell'entità è specificato dal tipo di media fornito nel campo di intestazione Content-Type. Il server di origine deve (MUST) creare la risorsa prima di restituire il codice di stato 201. Se l'azione non può essere eseguita immediatamente, il server dovrebbe (SHOULD) rispondere invece con la risposta 202 (Accepted).
Una risposta 201 può (MAY) contenere un campo di intestazione ETag che indica il valore corrente dell'entity tag per la variante di richiesta appena creata, vedere sezione 14.19.
10.2.3 202 Accepted (Accettato)
La richiesta è stata accettata per l'elaborazione, ma l'elaborazione non è stata completata. La richiesta potrebbe o potrebbe non essere eventualmente eseguita, poiché potrebbe non essere consentita quando si verifica effettivamente l'elaborazione. Non c'è alcuna possibilità di reinviare un codice di stato da tale operazione asincrona.
La risposta 202 è intenzionalmente non vincolante. 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. L'entità restituita con questa risposta dovrebbe (SHOULD) includere un'indicazione dello stato corrente della richiesta e un puntatore a un monitor di stato o una stima di quando l'utente può aspettarsi che la richiesta sia soddisfatta.
10.2.4 203 Non-Authoritative Information (Informazioni Non Autorevoli)
Le meta-informazioni restituite nell'intestazione dell'entità non provengono dall'insieme definitivo del server di origine, ma sono raccolte da una copia locale o di terze parti. L'insieme presentato può (MAY) essere un sottoinsieme o un superinsieme della versione originale. Ad esempio, l'inclusione di informazioni di annotazione locali sulla risorsa potrebbe risultare in un superinsieme delle meta-informazioni note dal server di origine. L'uso di questo codice di risposta non è richiesto ed è appropriato solo quando la risposta sarebbe altrimenti 200 (OK).
10.2.5 204 No Content (Nessun Contenuto)
Il server ha soddisfatto la richiesta ma non ha bisogno di restituire un corpo dell'entità e potrebbe voler restituire meta-informazioni aggiornate. La risposta può (MAY) includere nuove o aggiornate meta-informazioni sotto forma di intestazioni di entità, che, se presenti, dovrebbero (SHOULD) essere associate alla variante richiesta.
Se il client è un user agent, non dovrebbe (SHOULD NOT) cambiare la sua vista del documento da quella che ha causato l'invio della richiesta. Questa risposta è principalmente destinata a consentire che l'input per l'azione si verifichi senza causare un cambiamento nella vista del documento attivo dell'user agent, sebbene qualsiasi nuova o aggiornata meta-informazione dovrebbe (SHOULD) essere applicata al documento attualmente nella vista attiva dell'user agent.
La risposta 204 non deve (MUST NOT) includere un corpo del messaggio, ed è quindi sempre terminata dalla prima riga vuota dopo i campi di intestazione.
10.2.6 205 Reset Content (Ripristina Contenuto)
Il server ha soddisfatto la richiesta e l'user agent dovrebbe (SHOULD) ripristinare la vista del documento che ha causato l'invio della richiesta. Questa risposta è principalmente destinata a consentire l'input per l'azione di input dell'utente, seguita da una cancellazione del modulo in cui viene fornito l'input affinché l'utente possa facilmente avviare un'altra azione di input. La risposta non deve (MUST NOT) includere un'entità.
10.2.7 206 Partial Content (Contenuto Parziale)
Il server ha soddisfatto la richiesta GET parziale per la risorsa. La richiesta deve (MUST) aver incluso un campo di intestazione Range (sezione 14.35) che indica l'intervallo desiderato, e può (MAY) aver incluso un campo di intestazione If-Range (sezione 14.27) per rendere la richiesta condizionale.
La risposta deve (MUST) includere i seguenti campi di intestazione:
-
O un campo di intestazione Content-Range (sezione 14.16) che indica l'intervallo incluso in questa risposta, o un Content-Type multipart/byteranges che include campi Content-Range per ciascuna parte. Se un campo di intestazione Content-Length è presente nella risposta, il suo valore deve (MUST) corrispondere al numero effettivo di ottetti trasmessi nel corpo del messaggio.
-
Date
-
ETag e/o Content-Location, se l'intestazione sarebbe stata inviata in una risposta 200 alla stessa richiesta
-
Expires, Cache-Control, e/o Vary, se il valore del campo potrebbe differire da quello inviato in qualsiasi risposta precedente per la stessa variante
Se la risposta 206 è il risultato di una richiesta condizionale che utilizza un validatore di cache forte (vedere sezione 13.3.3), la risposta non dovrebbe (SHOULD NOT) includere altre intestazioni di entità. Ciò impedisce incoerenze tra corpi di entità memorizzati nella cache e intestazioni aggiornate. Altrimenti, la risposta deve (MUST) includere tutte le intestazioni di entità che sarebbero state restituite con una risposta 200 (OK) alla stessa richiesta.
Una cache non deve (MUST NOT) combinare una risposta 206 con altri contenuti precedentemente memorizzati nella cache se l'ETag o le intestazioni Last-Modified non corrispondono esattamente a quelli ricevuti in precedenza dal server di origine, e deve (MUST) trattare la risposta parziale come completa.
Una cache che non supporta le intestazioni Range e Content-Range non deve (MUST NOT) memorizzare nella cache risposte 206 (Partial).
10.3 Redirection 3xx (Reindirizzamento)
Questa classe di codice di stato indica che ulteriori azioni devono essere intraprese dall'user agent per soddisfare la richiesta. L'azione richiesta può (MAY) essere eseguita dall'user agent senza interazione con l'utente se e solo se il metodo utilizzato nella seconda richiesta è GET o HEAD. Un client dovrebbe (SHOULD) rilevare cicli di reindirizzamento infiniti, poiché tali cicli generano traffico di rete per ogni reindirizzamento.
Nota: Le versioni precedenti di questa specifica raccomandavano un massimo di cinque reindirizzamenti. Gli sviluppatori di contenuti dovrebbero essere consapevoli che potrebbero esserci client che non seguono questa raccomandazione.
10.3.1 300 Multiple Choices (Scelte Multiple)
La risorsa richiesta corrisponde a uno qualsiasi di un insieme di rappresentazioni, ciascuna con la propria posizione specifica, e vengono fornite informazioni di negoziazione guidata dall'agente (sezione 12) in modo che l'utente (o l'user agent) possa selezionare una rappresentazione preferita e reindirizzare la sua richiesta a quella posizione.
A meno che non si tratti di una richiesta HEAD, la risposta dovrebbe (SHOULD) includere un'entità contenente un elenco delle caratteristiche e delle posizioni delle risorse da cui l'utente o l'user agent può scegliere la più appropriata. Il formato dell'entità è specificato dal tipo di media fornito nel campo di intestazione Content-Type. A seconda del formato e delle capacità dell'user agent, la selezione della più appropriata potrebbe essere eseguita automaticamente. Tuttavia, questa specifica non definisce alcuno standard per tale selezione automatica.
Se il server ha una preferenza di scelta di rappresentazione, dovrebbe (SHOULD) includere l'URI specifico per quella rappresentazione nel campo Location; gli user agent possono (MAY) utilizzare il valore del campo Location per il reindirizzamento automatico. Questa risposta è memorizzabile nella cache a meno che non sia indicato diversamente.
10.3.2 301 Moved Permanently (Spostato Permanentemente)
Alla risorsa richiesta è stato assegnato un nuovo URI permanente, e qualsiasi riferimento futuro a questa risorsa dovrebbe (SHOULD) utilizzare uno degli URI restituiti. I client con capacità di modifica dei collegamenti dovrebbero (SHOULD) ricollegare automaticamente i riferimenti al Request-URI a uno o più dei nuovi riferimenti restituiti dal server, quando possibile. Questa risposta è memorizzabile nella cache a meno che non sia indicato diversamente.
Il nuovo URI permanente dovrebbe (SHOULD) essere fornito dal campo Location nella risposta. A meno che il metodo di richiesta non fosse HEAD, l'entità della risposta dovrebbe (SHOULD) contenere un breve collegamento ipertestuale al nuovo URI con una breve nota.
Se il codice di stato 301 viene ricevuto in risposta a una richiesta diversa da GET o HEAD, l'user agent non deve (MUST NOT) reindirizzare automaticamente la richiesta a meno che non possa essere confermata dall'utente, poiché ciò potrebbe cambiare le condizioni in cui la richiesta è stata emessa.
Nota: Quando si reindirizza automaticamente una richiesta POST, alcuni user agent HTTP/1.0 esistenti la cambieranno erroneamente in una richiesta GET.
10.3.3 302 Found
La risorsa richiesta risiede temporaneamente sotto un URI diverso. Poiché il reindirizzamento potrebbe essere modificato occasionalmente, il client dovrebbe (SHOULD) continuare a utilizzare il Request-URI per richieste future. Questa risposta è memorizzabile nella cache solo se indicato da un campo di intestazione Cache-Control o Expires.
L'URI temporaneo dovrebbe (SHOULD) essere fornito dal campo Location nella risposta. A meno che il metodo di richiesta non fosse HEAD, l'entità della risposta dovrebbe (SHOULD) contenere un breve collegamento ipertestuale al nuovo URI con una breve nota.
Se il codice di stato 302 viene ricevuto in risposta a una richiesta diversa da GET o HEAD, l'user agent non deve (MUST NOT) reindirizzare automaticamente la richiesta a meno che non possa essere confermata dall'utente, poiché ciò potrebbe cambiare le condizioni in cui la richiesta è stata emessa.
Nota: RFC 1945 e RFC 2068 specificavano che il client non era autorizzato a cambiare il metodo sulla richiesta reindirizzata. Tuttavia, la maggior parte delle implementazioni di user agent esistenti tratta 302 come se fosse una risposta 303, eseguendo un GET sul valore del campo Location indipendentemente dal metodo di richiesta originale. I codici di stato 303 e 307 sono stati aggiunti per i server che desiderano chiarire quale reazione ci si aspetta dal client.
10.3.4 303 See Other (Vedi Altro)
La risposta alla richiesta può essere trovata sotto un URI diverso e dovrebbe (SHOULD) essere recuperata utilizzando un metodo GET su quella risorsa. Questo metodo esiste principalmente per consentire all'output di un'azione attivata da POST di reindirizzare l'user agent a una risorsa selezionata. Il nuovo URI non è un riferimento sostitutivo per la risorsa richiesta originariamente. La risposta 303 non deve (MUST NOT) essere memorizzata nella cache, ma la risposta alla seconda richiesta (reindirizzata) potrebbe essere memorizzabile nella cache.
L'URI diverso dovrebbe essere fornito dal campo Location nella risposta. A meno che il metodo di richiesta non fosse HEAD, l'entità della risposta dovrebbe (SHOULD) contenere un breve collegamento ipertestuale al nuovo URI con una breve nota.
Nota: Molti user agent pre-HTTP/1.1 non comprendono lo stato 303. Quando l'interoperabilità con tali client è un problema, può essere utilizzato invece il codice di stato 302, poiché la maggior parte degli user agent reagisce a una risposta 302 come richiesto per una risposta 303.
10.3.5 304 Not Modified (Non Modificato)
Se il client ha eseguito una richiesta GET condizionale e l'accesso è consentito, ma il documento non è stato modificato, il server dovrebbe (SHOULD) rispondere con questo codice di stato. La risposta 304 non deve (MUST NOT) contenere un corpo del messaggio, ed è quindi sempre terminata dalla prima riga vuota dopo i campi di intestazione.
La risposta deve (MUST) includere i seguenti campi di intestazione:
- Date, a meno che la sua omissione non sia richiesta dalle regole nella sezione 14.18.1
Se un server di origine senza orologio obbedisce a queste regole, e proxy e client aggiungono il proprio Date a qualsiasi intestazione Date che ricevono, le cache funzioneranno correttamente.
- ETag e/o Content-Location, se l'intestazione sarebbe stata inviata in una risposta 200 alla stessa richiesta
- Expires, Cache-Control, e/o Vary, se il valore del campo potrebbe differire da quello inviato in qualsiasi risposta precedente per la stessa variante
Se il GET condizionale ha utilizzato un validatore di cache forte (vedere sezione 13.3.3), la risposta non dovrebbe (SHOULD NOT) includere altre intestazioni di entità. Altrimenti (cioè, il GET condizionale ha utilizzato un validatore debole), la risposta non deve (MUST NOT) includere altre intestazioni di entità; ciò impedisce incoerenze tra corpi di entità memorizzati nella cache e intestazioni aggiornate.
Se una risposta 304 indica un'entità che non è attualmente memorizzata nella cache, la cache deve (MUST) ignorare la risposta e ripetere la richiesta senza la condizione.
Se una cache riceve una risposta 304 che aggiorna una voce di cache che ha attualmente memorizzato nella cache, la cache deve (MUST) aggiornare la voce per riflettere qualsiasi nuovo valore di campo fornito nella risposta.
10.3.6 305 Use Proxy (Usa Proxy)
Alla risorsa richiesta deve (MUST) essere acceduto tramite il proxy fornito dal campo Location. Il campo Location fornisce l'URI del proxy. Il destinatario è tenuto a ripetere questa singola richiesta tramite il proxy. Le risposte 305 devono (MUST) essere generate solo dai server di origine.
Nota: RFC 2068 non specificava chiaramente che 305 era destinato a reindirizzare una singola richiesta a un proxy. La memorizzazione nella cache inappropriata delle risposte 305 ha causato significativi problemi di sicurezza dirigendo le richieste successive a quel proxy.
10.3.7 306 (Unused) (Non Utilizzato)
Il codice di stato 306 era utilizzato in una versione precedente della specifica, non è più utilizzato e il codice è riservato.
10.3.8 307 Temporary Redirect (Reindirizzamento Temporaneo)
La risorsa richiesta risiede temporaneamente sotto un URI diverso. Poiché il reindirizzamento potrebbe essere modificato occasionalmente, il client dovrebbe (SHOULD) continuare a utilizzare il Request-URI per richieste future. Questa risposta è memorizzabile nella cache solo se indicato da un campo di intestazione Cache-Control o Expires.
L'URI temporaneo dovrebbe (SHOULD) essere fornito dal campo Location nella risposta. A meno che il metodo di richiesta non fosse HEAD, l'entità della risposta dovrebbe (SHOULD) contenere un breve collegamento ipertestuale al nuovo URI con una breve nota, poiché molti user agent pre-HTTP/1.1 non comprendono lo stato 307. Pertanto, la nota dovrebbe (SHOULD) contenere le informazioni necessarie affinché un utente ripeta la richiesta originale sul nuovo URI.
Se il codice di stato 307 viene ricevuto in risposta a una richiesta diversa da GET o HEAD, l'user agent non deve (MUST NOT) reindirizzare automaticamente la richiesta a meno che non possa essere confermata dall'utente, poiché ciò potrebbe cambiare le condizioni in cui la richiesta è stata emessa.
10.4 Client Error 4xx (Errore del Client)
La classe di codice di stato 4xx è destinata ai casi in cui il client sembra aver commesso un errore. Tranne quando si risponde a una richiesta HEAD, il server dovrebbe (SHOULD) includere un'entità 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 (SHOULD) visualizzare qualsiasi entità inclusa all'utente.
Se il client sta inviando dati, un'implementazione del server che utilizza TCP dovrebbe (SHOULD) fare attenzione a garantire che il client riconosca la ricezione dei pacchetti contenenti la risposta, prima che il server chiuda la connessione di input. Se il client continua a inviare dati al server dopo la chiusura, lo stack TCP del server invierà un pacchetto di reset al client, che potrebbe cancellare i buffer di input non riconosciuti del client prima che l'applicazione HTTP possa leggerli e interpretarli.
10.4.1 400 Bad Request (Richiesta Errata)
La richiesta non poteva essere compresa dal server a causa di una sintassi malformata. Il client non dovrebbe (SHOULD NOT) ripetere la richiesta senza modifiche.
10.4.2 401 Unauthorized (Non Autorizzato)
La richiesta richiede l'autenticazione dell'utente. La risposta deve (MUST) includere un campo di intestazione WWW-Authenticate (sezione 14.47) contenente una sfida applicabile alla risorsa richiesta. Il client può (MAY) ripetere la richiesta con un campo di intestazione Authorization appropriato (sezione 14.8). Se la richiesta includeva già credenziali Authorization, allora la risposta 401 indica che l'autorizzazione è stata negata per quelle credenziali. Se la risposta 401 contiene la stessa sfida di una risposta precedente, e l'user agent ha già tentato l'autenticazione almeno una volta, allora l'entità fornita nella risposta dovrebbe (SHOULD) essere presentata all'utente, poiché quell'entità potrebbe includere informazioni diagnostiche rilevanti. L'autenticazione di accesso HTTP è spiegata in "HTTP Authentication: Basic and Digest Access Authentication" [43].
10.4.3 402 Payment Required (Pagamento Richiesto)
Questo codice è riservato per uso futuro.
10.4.4 403 Forbidden (Vietato)
Il server ha compreso la richiesta, ma si rifiuta di soddisfarla. L'autorizzazione non aiuterà e la richiesta non dovrebbe (SHOULD NOT) essere ripetuta. Se il metodo di richiesta non era HEAD e il server desidera rendere pubblico il motivo per cui la richiesta non è stata soddisfatta, dovrebbe (SHOULD) descrivere il motivo del rifiuto nell'entità. Se il server non desidera rendere queste informazioni disponibili al client, può essere utilizzato invece il codice di stato 404 (Not Found).
10.4.5 404 Not Found (Non Trovato)
Il server non ha trovato nulla che corrisponda al Request-URI. Non viene fornita alcuna indicazione se la condizione è temporanea o permanente. Il codice di stato 410 (Gone) dovrebbe (SHOULD) essere utilizzato se il server sa, tramite un meccanismo configurabile internamente, che una vecchia risorsa è permanentemente non disponibile e non ha un indirizzo di inoltro. Questo codice di stato è comunemente utilizzato quando il server non desidera rivelare esattamente perché la richiesta è stata rifiutata, o quando nessun'altra risposta è applicabile.
10.4.6 405 Method Not Allowed (Metodo Non Consentito)
Il metodo specificato nella Request-Line non è consentito per la risorsa identificata dal Request-URI. La risposta deve (MUST) includere un'intestazione Allow contenente un elenco di metodi validi per la risorsa richiesta.
10.4.7 406 Not Acceptable (Non Accettabile)
La risorsa identificata dalla richiesta è in grado di generare solo entità di risposta le cui caratteristiche di contenuto non sono accettabili secondo le intestazioni accept inviate nella richiesta.
A meno che non si tratti di una richiesta HEAD, la risposta dovrebbe (SHOULD) includere un'entità contenente un elenco delle caratteristiche e delle posizioni delle entità disponibili da cui l'utente o l'user agent può scegliere la più appropriata. Il formato dell'entità è specificato dal tipo di media fornito nel campo di intestazione Content-Type. A seconda del formato e delle capacità dell'user agent, la selezione della più appropriata potrebbe essere eseguita automaticamente. Tuttavia, questa specifica non definisce alcuno standard per tale selezione automatica.
Nota: I server HTTP/1.1 sono autorizzati a restituire risposte che non sono accettabili secondo le intestazioni accept inviate nella richiesta. In alcuni casi, questo potrebbe anche essere preferibile all'invio di una risposta 406. Gli user agent sono incoraggiati a ispezionare le intestazioni di una risposta in arrivo per determinare se è accettabile.
Se la risposta potrebbe essere inaccettabile, un user agent dovrebbe (SHOULD) temporaneamente interrompere la ricezione di ulteriori dati e interrogare l'utente per una decisione sull'azione ulteriore.
10.4.8 407 Proxy Authentication Required (Autenticazione Proxy Richiesta)
Questo codice è simile a 401 (Unauthorized), ma indica che il client deve prima autenticarsi con il proxy. Il proxy deve (MUST) restituire un campo di intestazione Proxy-Authenticate (sezione 14.33) contenente una sfida applicabile al proxy per la risorsa richiesta. Il client può (MAY) ripetere la richiesta con un campo di intestazione Proxy-Authorization appropriato (sezione 14.34). L'autenticazione di accesso HTTP è spiegata in "HTTP Authentication: Basic and Digest Access Authentication" [43].
10.4.9 408 Request Timeout (Timeout della Richiesta)
Il client non ha prodotto una richiesta entro il tempo in cui il server era preparato ad attendere. Il client può (MAY) ripetere la richiesta senza modifiche in qualsiasi momento successivo.
10.4.10 409 Conflict (Conflitto)
La richiesta non ha potuto essere completata a causa di un conflitto con lo stato corrente della risorsa. Questo codice è consentito solo in situazioni in cui ci si aspetta che l'utente possa essere in grado di risolvere il conflitto e reinviare la richiesta. Il corpo della risposta dovrebbe (SHOULD) includere informazioni sufficienti affinché l'utente riconosca la fonte del conflitto. Idealmente, l'entità della risposta includerebbe informazioni sufficienti affinché l'utente o l'user agent risolva il problema; tuttavia, ciò potrebbe non essere possibile e non è richiesto.
I conflitti sono più probabili in risposta a una richiesta PUT. Ad esempio, se si utilizzava il versionamento e l'entità messa con PUT includeva modifiche a una risorsa in conflitto con quelle apportate da una richiesta (di terze parti) precedente, il server potrebbe utilizzare una risposta 409 per indicare che non può completare la richiesta. In questo caso, l'entità della risposta conterrebbe probabilmente un elenco delle differenze tra le due versioni in un formato definito dal Content-Type della risposta.
10.4.11 410 Gone (Scomparso)
La risorsa richiesta non è più disponibile sul server e non è noto alcun indirizzo di inoltro. Questa condizione è prevista essere permanente. I client con capacità di modifica dei collegamenti dovrebbero (SHOULD) eliminare i riferimenti al Request-URI dopo l'approvazione dell'utente. Se il server non sa, o non ha alcuna possibilità di determinare, se la condizione è permanente, dovrebbe (SHOULD) essere utilizzato invece il codice di stato 404 (Not Found). Questa risposta è memorizzabile nella cache a meno che non sia indicato diversamente.
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 i servizi promozionali a tempo limitato e per le risorse appartenenti a individui che non lavorano più sul sito del server di origine. Non è necessario marcare tutte le risorse permanentemente non disponibili come "scomparse" o mantenere il segno per qualsiasi periodo di tempo - questo è lasciato alla discrezione del proprietario del server.
10.4.12 411 Length Required (Lunghezza Richiesta)
Il server rifiuta di accettare la richiesta senza un Content-Length definito. Il client può (MAY) ripetere la richiesta se aggiunge un campo di intestazione Content-Length valido contenente la lunghezza del corpo del messaggio nel messaggio di richiesta.
10.4.13 412 Precondition Failed (Precondizione Fallita)
La precondizione fornita in uno o più dei campi di intestazione della richiesta è stata valutata come falsa quando testata sul server. Questo codice di stato consente al client di porre precondizioni sulle meta-informazioni della risorsa corrente (dati del campo di intestazione) e quindi impedire che il metodo di richiesta venga applicato a una risorsa diversa da quella prevista.
10.4.14 413 Request Entity Too Large (Entità della Richiesta Troppo Grande)
Il server rifiuta di elaborare una richiesta perché l'entità della richiesta è più grande di quanto il server sia disposto o in grado di elaborare. Il server può (MAY) chiudere la connessione per impedire al client di continuare la richiesta.
Se la condizione è temporanea, il server dovrebbe (SHOULD) includere un campo di intestazione Retry-After per indicare che è temporanea e dopo quale tempo il client può riprovare.
10.4.15 414 Request-URI Too Long (Request-URI Troppo Lungo)
Il server rifiuta di servire la richiesta perché il Request-URI è più lungo di quanto il server sia disposto a interpretare. Questa rara condizione si verificherà solo quando: un client ha convertito erroneamente una richiesta POST in una richiesta GET con lunghe informazioni di query, quando il client è sceso in un "buco nero" di reindirizzamento (ad esempio, un prefisso di reindirizzamento che punta a un suffisso di se stesso), o quando il server è sotto attacco da un client che tenta di sfruttare i buchi di sicurezza presenti in alcuni server utilizzando buffer di lunghezza fissa per leggere o manipolare il Request-URI.
10.4.16 415 Unsupported Media Type (Tipo di Media Non Supportato)
Il server rifiuta di servire la richiesta perché l'entità della richiesta è in un formato non supportato dalla risorsa richiesta per il metodo richiesto.
10.4.17 416 Requested Range Not Satisfiable (Intervallo Richiesto Non Soddisfacibile)
Un server dovrebbe (SHOULD) restituire una risposta con questo codice di stato se una richiesta includeva un campo di intestazione di richiesta Range (sezione 14.35), e nessuno dei valori dello specificatore di intervallo in quel campo si sovrappone all'intervallo corrente della risorsa selezionata, e la richiesta non includeva un campo di intestazione di richiesta If-Range. (Per intervalli di byte, ciò significa che la posizione del primo byte di tutti i valori byte-range-spec era maggiore della lunghezza corrente della risorsa selezionata.)
Quando questo codice di stato viene restituito per un intervallo di byte, la risposta dovrebbe (SHOULD) includere un campo di intestazione di entità Content-Range specificando la lunghezza corrente della risorsa selezionata (vedere sezione 14.16). Questa risposta non deve (MUST NOT) utilizzare il content-type multipart/byteranges.
10.4.18 417 Expectation Failed (Aspettativa Fallita)
L'aspettativa fornita in un campo di intestazione di richiesta Expect (vedere sezione 14.20) non ha potuto essere soddisfatta da questo server, o, se il server è un proxy, il server ha prove inequivocabili che la richiesta non può essere soddisfatta dal server del prossimo hop.
10.5 Server Error 5xx (Errore del Server)
I codici di stato di risposta che iniziano con la cifra "5" indicano casi in cui il server è consapevole di aver commesso un errore o è incapace di eseguire la richiesta. Tranne quando si risponde a una richiesta HEAD, il server dovrebbe (SHOULD) includere un'entità contenente una spiegazione della situazione di errore, e se si tratta di una condizione temporanea o permanente. Gli user agent dovrebbero (SHOULD) visualizzare qualsiasi entità inclusa all'utente. Questi codici di risposta sono applicabili a qualsiasi metodo di richiesta.
10.5.1 500 Internal Server Error (Errore Interno del Server)
Il server ha incontrato una condizione inaspettata che gli ha impedito di soddisfare la richiesta.
10.5.2 501 Not Implemented (Non Implementato)
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 nessuna risorsa.
10.5.3 502 Bad Gateway (Gateway Errato)
Il server, mentre fungeva da gateway o proxy, ha ricevuto una risposta non valida dal server upstream a cui ha avuto accesso nel tentativo di soddisfare la richiesta.
10.5.4 503 Service Unavailable (Servizio Non Disponibile)
Il server è attualmente incapace di gestire la richiesta a causa di un sovraccarico temporaneo o manutenzione del server. Ciò implica che si tratta di una condizione temporanea che sarà alleviata dopo un certo ritardo. Se nota, la durata del ritardo può (MAY) essere indicata in un'intestazione Retry-After. Se non viene fornito alcun Retry-After, il client dovrebbe (SHOULD) gestire la risposta come se fosse una risposta 500.
Nota: L'esistenza del codice di stato 503 non implica che un server debba utilizzarlo durante il sovraccarico. Alcuni server potrebbero semplicemente voler rifiutare la connessione.
10.5.5 504 Gateway Timeout (Timeout del Gateway)
Il server, mentre fungeva da gateway o proxy, non ha ricevuto una risposta tempestiva dal server upstream che doveva accedere per completare la richiesta.
Nota: Si noti che 408 (Request Timeout) dovrebbe essere distinto da questo codice di stato.
10.5.6 505 HTTP Version Not Supported (Versione HTTP Non Supportata)
Il server non supporta, o rifiuta di supportare, la versione del protocollo HTTP che è stata utilizzata nel messaggio di richiesta. Il server sta indicando che è incapace o non disposto a completare la richiesta utilizzando la stessa versione principale del client, come descritto nella sezione 3.1, diversamente dall'uso di questo messaggio di errore. La risposta dovrebbe (SHOULD) contenere un'entità che descrive perché quella versione non è supportata e quali altri protocolli sono supportati da quel server.