Simile agli strumenti di download HTTP come FlashGet o Thunder, tutti usano questo tipo di risposta per implementare download riprendibili o dividere un documento di grandi dimensioni in più segmenti per il download simultaneo.

Questa richiesta deve includere informazioni sull'intestazione Range per indicare l'intervallo di contenuto che il client desidera ottenere e può includere If-Range come condizione della richiesta.

La risposta deve includere i seguenti campi di intestazione:

• Content-Range è usato per indicare l'intervallo di contenuto restituito in questa risposta; se si tratta di un download multi-segmento con Content-Type come multipart/byteranges, ogni segmento multipart dovrebbe contenere un campo Content-Range per indicare l'intervallo di contenuto di questo segmento. Se la risposta contiene Content-Length, il suo valore deve corrispondere al numero effettivo di byte nell'intervallo di contenuto restituito.
• Date
• ETag e/o Content-Location, se la stessa richiesta avrebbe dovuto restituire una risposta 200.
• Expires, Cache-Control e/o Vary, se i loro valori potrebbero essere diversi dai valori corrispondenti ad altre risposte della stessa variabile in precedenza.

Se questa richiesta di risposta utilizza la convalida della cache forte If-Range, questa risposta non deve contenere altre intestazioni di entità; se questa richiesta di risposta utilizza la convalida della cache debole If-Range, questa risposta è vietata dal contenere altre intestazioni di entità; questo evita l'incoerenza tra contenuto dell'entità memorizzato nella cache e informazioni sull'intestazione dell'entità aggiornate. Altrimenti, questa risposta dovrebbe contenere tutti i campi di intestazione dell'entità che dovrebbero essere restituiti in una risposta 200.

Se le intestazioni ETag o Last-Modified non possono essere esattamente abbinate, la cache del client dovrebbe proibire di combinare il contenuto restituito dalla risposta 206 con qualsiasi contenuto precedentemente memorizzato nella cache.

Qualsiasi cache che non supporta le intestazioni Range e Content-Range è vietata dal memorizzare nella cache il contenuto restituito dalla risposta 206.

La risorsa richiesta è stata spostata in modo permanente in una nuova posizione e qualsiasi riferimento futuro a questa risorsa deve utilizzare uno dei vari URI restituiti da questa risposta. Se possibile, i client con funzionalità di modifica dei link dovrebbero modificare automaticamente l'indirizzo della richiesta all'indirizzo fornito dal server. Salvo diversa indicazione, questa risposta è anche memorizzabile nella cache.

Il nuovo URI permanente dovrebbe essere restituito nel campo Location della risposta. A meno che non si tratti di una richiesta HEAD, l'entità della risposta dovrebbe contenere un collegamento ipertestuale al nuovo URI e una breve descrizione.

Se questa non è una richiesta GET o HEAD, i browser sono quindi vietati dal reindirizzare automaticamente a meno che non venga ottenuta la conferma dell'utente, poiché le condizioni della richiesta potrebbero cambiare di conseguenza.

Nota: per alcuni browser che utilizzano il protocollo HTTP/1.0, quando inviano una richiesta POST e ottengono una risposta 301, la successiva richiesta di reindirizzamento diventerà un metodo GET.

La risorsa richiesta risponde ora temporaneamente alle richieste da un URI diverso. Poiché tali reindirizzamenti sono temporanei, i client devono continuare a inviare richieste future all'indirizzo originale. Questa risposta è memorizzabile nella cache solo se specificato in Cache-Control o Expires.

Il nuovo URI temporaneo dovrebbe essere restituito nel campo Location della risposta. A meno che non si tratti di una richiesta HEAD, l'entità della risposta dovrebbe contenere un collegamento ipertestuale al nuovo URI e una breve descrizione.

Se questa non è una richiesta GET o HEAD, i browser sono vietati dal reindirizzare automaticamente a meno che non venga ottenuta la conferma dell'utente, poiché le condizioni della richiesta potrebbero cambiare di conseguenza.

L'esistenza di questo metodo è principalmente per consentire l'output della richiesta POST attivato dagli script di reindirizzare a una nuova risorsa. Questo nuovo URI non è un riferimento sostitutivo per la risorsa originale.

Simile al 302, ma il codice di stato 307 non consente ai browser di reindirizzare una richiesta originariamente POST a una richiesta GET.

Simile al 301, ma il codice di stato 308 non consente ai browser di reindirizzare una richiesta originariamente POST a una richiesta GET.

Le risposte 304 sono vietate dal contenere un corpo del messaggio, quindi terminano sempre con la prima riga vuota dopo l'intestazione del messaggio.

La risposta deve contenere una delle seguenti informazioni di intestazione: Date, ETag, Server, Vary a meno che queste informazioni di intestazione non siano già state impostate nella cache.

Il client non dovrebbe inviare nuovamente questa richiesta senza modifiche.

Questo codice di stato indica che la richiesta corrente richiede l'autenticazione dell'utente. La risposta deve contenere un'intestazione di informazione WWW-Authenticate applicabile alla risorsa richiesta per interrogare le informazioni dell'utente.

Il client può inviare nuovamente una richiesta contenente informazioni di intestazione Authorization appropriate. Se la richiesta corrente contiene già credenziali Authorization, allora una risposta 401 rappresenta che l'autenticazione del server ha rifiutato quelle credenziali.

A differenza della risposta 401, l'autenticazione non può fornire alcun aiuto e questa richiesta non dovrebbe essere inviata nuovamente. Se questa non è una richiesta HEAD e il server desidera essere in grado di spiegare perché la richiesta non può essere eseguita, il motivo del rifiuto dovrebbe essere descritto nell'entità.

Naturalmente, il server può anche restituire una risposta 404 se non vuole che il client ottenga alcuna informazione.

Nessuna informazione può dire all'utente se questa situazione è temporanea o permanente. Se il server conosce la situazione, dovrebbe usare il codice di stato 410 per informare che la vecchia risorsa è permanentemente non disponibile a causa di alcuni problemi di meccanismo di configurazione interna e non c'è un indirizzo a cui saltare.

Il codice di stato 404 è ampiamente utilizzato quando il server non vuole rivelare esattamente perché la richiesta è stata rifiutata o non è disponibile altra risposta adeguata.

La risposta deve restituire un'informazione di intestazione Allow per indicare l'elenco dei metodi di richiesta che la risorsa corrente può accettare.

Poiché i metodi PUT e DELETE eseguiranno operazioni di scrittura sulle risorse sul server, la maggior parte dei server web non supporta o non consente i metodi di richiesta sopra indicati nella configurazione predefinita e restituirà errori 405 per tali richieste.

Il client non ha completato l'invio di una richiesta entro il tempo che il server era disposto ad attendere. Il client può inviare nuovamente questa richiesta in qualsiasi momento senza alcuna modifica.

Questo codice è consentito solo in tali situazioni: si ritiene che gli utenti siano in grado di risolvere il conflitto e invieranno nuove richieste.

Tale situazione dovrebbe essere considerata permanente. Se possibile, i client con funzionalità di modifica dei link dovrebbero eliminare tutti i riferimenti che puntano a questo indirizzo.

In questo caso, il server può chiudere la connessione per impedire al client di continuare a inviare questa richiesta.

La risposta può contenere un'intestazione Retry-After, che suggerisce quanto tempo l'utente dovrebbe aspettare prima di riprovare.

Il server ha riscontrato una situazione inaspettata che gli ha impedito di completare l'elaborazione della richiesta. In generale, questo problema si verifica quando c'è un errore nel codice del programma del server.

Quando il server non può riconoscere il metodo di richiesta e non può supportare la sua richiesta per qualsiasi risorsa, questo codice di stato è appropriato.

Gli errori 502 di solito non possono essere risolti dal client, ma devono essere risolti dal server web o dal server proxy intermedio.

Di solito, questo è solo uno stato temporaneo. Se il tempo di ritardo può essere previsto, la risposta può includere un'intestazione Retry-After per indicare questo tempo di ritardo. Se questa informazione Retry-After non viene fornita, il client dovrebbe gestirlo nello stesso modo in cui gestisce una risposta 500.

Nota: alcuni server proxy restituiscono errori 400 o 500 quando le query DNS scadono.