HTTP - Campi intestazione

I campi di intestazione HTTP forniscono le informazioni obbligatorie sulla richiesta o risposta o sull'oggetto inviato nel corpo del messaggio. Esistono quattro tipi di intestazioni dei messaggi HTTP:

• General-header: Questi campi di intestazione hanno applicabilità generale sia per i messaggi di richiesta che per i messaggi di risposta.

• Client Request-header: Questi campi di intestazione hanno applicabilità solo per i messaggi di richiesta.

• Server Response-header: Questi campi di intestazione possono essere applicati solo ai messaggi di risposta.

• Entity-header: Questi campi di intestazione definiscono le meta informazioni sul corpo dell'entità o, se non è presente alcun corpo, sulla risorsa identificata dalla richiesta.

Intestazioni generali

Cache-Control

Il campo Cache-Control general-header viene utilizzato per specificare le direttive che DEVONO essere obbedite da tutto il sistema di caching. La sintassi è la seguente:

Cache-Control : cache-request-directive|cache-response-directive

Un client o un server HTTP può utilizzare l'estensione Cache-controlintestazione generale per specificare i parametri per la cache o per richiedere determinati tipi di documenti dalla cache. Le direttive di memorizzazione nella cache sono specificate in un elenco separato da virgole. Per esempio:

Cache-control: no-cache

La tabella seguente elenca le importanti direttive di richiesta cache che possono essere utilizzate dal client nella sua richiesta HTTP:

SN	Direttiva e descrizione della richiesta di cache
1	no-cache Una cache non deve utilizzare la risposta per soddisfare una richiesta successiva senza una riconvalida riuscita con il server di origine.
2	no-store La cache non dovrebbe memorizzare nulla sulla richiesta del client o sulla risposta del server.
3	max-age = seconds Indica che il client è disposto ad accettare una risposta la cui età non è maggiore del tempo specificato in secondi.
4	max-stale [ = seconds ] Indica che il client è disposto ad accettare una risposta che ha superato il tempo di scadenza. Se vengono forniti dei secondi, non deve essere scaduto più di quel tempo.
5	min-fresh = seconds Indica che il client è disposto ad accettare una risposta la cui durata di aggiornamento non è inferiore alla sua età corrente più il tempo specificato in secondi.
6	no-transform Non converte l'entità-corpo.
7	only-if-cached Non recupera nuovi dati. La cache può inviare un documento solo se è nella cache e non deve contattare il server di origine per vedere se esiste una copia più recente.

Le seguenti importanti direttive di risposta della cache che possono essere utilizzate dal server nella sua risposta HTTP:

SN	Direttiva e descrizione della risposta della cache
1	public Indica che la risposta può essere memorizzata nella cache da qualsiasi cache.
2	private Indica che tutto o parte del messaggio di risposta è destinato a un singolo utente e non deve essere memorizzato nella cache da una cache condivisa.
3	no-cache Una cache non deve utilizzare la risposta per soddisfare una richiesta successiva senza una nuova convalida riuscita con il server di origine.
4	no-store La cache non dovrebbe memorizzare nulla sulla richiesta del client o sulla risposta del server.
5	no-transform Non converte l'entità-corpo.
6	must-revalidate La cache deve verificare lo stato dei documenti obsoleti prima di utilizzarla e quelli scaduti non devono essere utilizzati.
7	proxy-revalidate La direttiva proxy-revalidate ha lo stesso significato della direttiva must-revalidate, tranne per il fatto che non si applica alle cache degli user agent non condivise.
8	max-age = seconds Indica che il client è disposto ad accettare una risposta la cui età non è maggiore del tempo specificato in secondi.
9	s-maxage = seconds L'età massima specificata da questa direttiva sostituisce l'età massima specificata dalla direttiva max-age o dall'intestazione Expires. La direttiva s-maxage viene sempre ignorata da una cache privata.

Connessione

Il campo di intestazione generale della connessione consente al mittente di specificare le opzioni desiderate per quella particolare connessione e non devono essere comunicate dai proxy su ulteriori connessioni. Di seguito è riportata la semplice sintassi per l'utilizzo dell'intestazione della connessione:

Connection : "Connection"

HTTP / 1.1 definisce l'opzione di "chiusura" della connessione per il mittente per segnalare che la connessione verrà chiusa dopo il completamento della risposta. Per esempio:

Connection: close

Per impostazione predefinita, HTTP 1.1 utilizza connessioni persistenti, in cui la connessione non si chiude automaticamente dopo una transazione. HTTP 1.0, d'altra parte, non ha connessioni persistenti per impostazione predefinita. Se un client 1.0 desidera utilizzare connessioni persistenti, utilizza l'estensionekeep-alive parametro come segue:

Connection: keep-alive

Data

Tutti i timestamp di data / ora HTTP DEVONO essere rappresentati in Greenwich Mean Time (GMT), senza eccezioni. Le applicazioni HTTP possono utilizzare una delle seguenti tre rappresentazioni di data / ora:

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

Qui il primo formato è quello preferito.

Pragma

Il campo di intestazione generale Pragma viene utilizzato per includere direttive specifiche di implementazione che potrebbero applicarsi a qualsiasi destinatario lungo la catena di richiesta / risposta. Per esempio:

Pragma: no-cache

L'unica direttiva definita in HTTP / 1.0 è la direttiva no-cache ed è mantenuta in HTTP 1.1 per compatibilità con le versioni precedenti. In futuro non verranno definite nuove direttive Pragma.

trailer

Il valore del campo generale Trailer indica che il set specificato di campi di intestazione è presente nel trailer di un messaggio codificato con codifica di trasferimento in blocchi. Di seguito è riportata la sintassi del campo dell'intestazione del trailer:

Trailer : field-name

I campi dell'intestazione del messaggio elencati nel campo dell'intestazione del trailer non devono includere i seguenti campi dell'intestazione:

• Transfer-Encoding

• Content-Length

• Trailer

Codifica di trasferimento

Il campo Transfer-Encoding general-header indica il tipo di trasformazione applicato al corpo del messaggio per trasferirlo in sicurezza tra il mittente e il destinatario. Non è la stessa cosa della codifica del contenuto perché le codifiche di trasferimento sono una proprietà del messaggio, non del corpo dell'entità. La sintassi del campo di intestazione Transfer-Encoding è la seguente:

Transfer-Encoding: chunked

Tutti i valori di codifica di trasferimento non fanno distinzione tra maiuscole e minuscole.

Upgrade

L' intestazione generale Upgrade consente al client di specificare quali protocolli di comunicazione aggiuntivi supporta e desidera utilizzare se il server ritiene appropriato cambiare protocollo. Per esempio:

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Il campo di intestazione Upgrade ha lo scopo di fornire un semplice meccanismo per la transizione da HTTP / 1.1 a qualche altro protocollo incompatibile.

attraverso

L' intestazione generale Via deve essere utilizzata da gateway e proxy per indicare i protocolli intermedi e i destinatari. Ad esempio, un messaggio di richiesta potrebbe essere inviato da un agente utente HTTP / 1.0 a un proxy interno denominato "fred", che utilizza HTTP / 1.1 per inoltrare la richiesta a un proxy pubblico su nowhere.com, che completa la richiesta tramite inoltrandolo al server di origine su www.ics.uci.edu. La richiesta ricevuta da www.ics.uci.edu avrebbe quindi il seguente campo di intestazione Via:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Il campo di intestazione Upgrade ha lo scopo di fornire un semplice meccanismo per la transizione da HTTP / 1.1 a qualche altro protocollo incompatibile.

avvertimento

L' intestazione generale Avviso viene utilizzata per fornire informazioni aggiuntive sullo stato o sulla trasformazione di un messaggio che potrebbero non essere riflesse nel messaggio. Una risposta può contenere più di un'intestazione di avviso.

Warning : warn-code SP warn-agent SP warn-text SP warn-date

Intestazioni richieste client

Accettare

Il campo Accetta richiesta-intestazione può essere utilizzato per specificare alcuni tipi di media che sono accettabili per la risposta. La sintassi generale è la seguente:

Accept: type/subtype [q=qvalue]

È possibile elencare più tipi di supporto separati da virgole e il qvalue facoltativo rappresenta un livello di qualità accettabile per i tipi di accettazione su una scala da 0 a 1. Di seguito è riportato un esempio:

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

Questo verrebbe interpretato come text/html e text/x-c e sono i tipi di media preferiti, ma se non esistono, invia il file text/x-dvi entità e, se non esiste, invia il file text/plain entità.

Accetta set di caratteri

Il campo Accept-Charset request-header può essere utilizzato per indicare quali set di caratteri sono accettabili per la risposta. Di seguito è riportata la sintassi generale:

Accept-Charset: character_set [q=qvalue]

È possibile elencare più set di caratteri separati da virgole e il qvalue opzionale rappresenta un livello di qualità accettabile per set di caratteri non preferiti su una scala da 0 a 1. Di seguito è riportato un esempio:

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

Il valore speciale "*", se presente nel file Accept-Charset campo, corrisponde a ogni set di caratteri e se no Accept-Charset l'intestazione è presente, l'impostazione predefinita è che qualsiasi set di caratteri è accettabile.

Accetta codifica

Il campo Accept-Encoding request-header è simile ad Accept, ma limita le codifiche del contenuto accettabili nella risposta. La sintassi generale è:

Accept-Encoding: encoding types

Gli esempi sono i seguenti:

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Accetta la lingua

Il campo di intestazione della richiesta Accept-Language è simile ad Accept, ma limita il set di linguaggi naturali preferiti come risposta alla richiesta. La sintassi generale è:

Accept-Language: language [q=qvalue]

È possibile elencare più lingue separate da virgole e il qvalue facoltativo rappresenta un livello di qualità accettabile per le lingue non preferite su una scala da 0 a 1. Di seguito è riportato un esempio:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Autorizzazione

Il valore del campo di intestazione della richiesta di autorizzazione consiste di credenziali contenenti le informazioni di autenticazione dell'agente utente per l'ambito della risorsa richiesta. La sintassi generale è:

Authorization : credentials

La specifica HTTP / 1.0 definisce lo schema di autorizzazione BASIC, dove il parametro di autorizzazione è la stringa di username:password codificato in base 64. Di seguito è riportato un esempio:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

Il valore viene decodificato in è guest:guest123 dove guest è l'ID utente e guest123 è la password.

Cookie

Il valore del campo Intestazione richiesta cookie contiene una coppia di informazioni nome / valore memorizzata per quell'URL. Di seguito è riportata la sintassi generale:

Cookie: name=value

È possibile specificare più cookie separati da punto e virgola come segue:

Cookie: name1=value1;name2=value2;name3=value3

Aspettarsi

Il campo Expect request-header viene utilizzato per indicare che un particolare insieme di comportamenti del server è richiesto dal client. La sintassi generale è:

Expect : 100-continue | expectation-extension

Se un server riceve una richiesta contenente un campo Expect che include un'estensione dell'aspettativa che non supporta, deve rispondere con uno stato 417 (Expectation Failed).

A partire dal

Il campo Da intestazione richiesta contiene un indirizzo di posta elettronica Internet per l'utente umano che controlla l'agente utente richiedente. Di seguito è riportato un semplice esempio:

From: [email protected]

Questo campo di intestazione può essere utilizzato per scopi di registrazione e come mezzo per identificare l'origine di richieste non valide o indesiderate.

Ospite

Il campo di intestazione della richiesta host viene utilizzato per specificare l'host Internet e il numero di porta della risorsa richiesta. La sintassi generale è:

Host : "Host" ":" host [ ":" port ] ;

UN hostsenza alcuna informazione sulla porta finale implica la porta predefinita, che è 80. Ad esempio, una richiesta sul server di origine per http://www.w3.org/pub/WWW/ sarebbe:

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

If-Match

Il campo di intestazione della richiesta If-Match viene utilizzato con un metodo per renderlo condizionale. Questa intestazione richiede al server di eseguire il metodo richiesto solo se il valore specificato in questo tag corrisponde ai tag di entità specificati rappresentati daETag. La sintassi generale è:

If-Match : entity-tag

Un asterisco (*) corrisponde a qualsiasi entità e la transazione continua solo se l'entità esiste. Di seguito sono possibili esempi:

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

Se nessuno dei tag di entità corrisponde o se viene fornito "*" e non esiste alcuna entità corrente, il server non deve eseguire il metodo richiesto e deve restituire una risposta 412 (Precondizione non riuscita).

If-Modified-Since

Il campo dell'intestazione della richiesta If-Modified-Since viene utilizzato con un metodo per renderlo condizionale. Se l'URL richiesto non è stato modificato dall'ora specificata in questo campo, un'entità non verrà restituita dal server; invece, verrà restituita una risposta 304 (non modificata) senza alcun corpo del messaggio. La sintassi generale di if-modified-since è:

If-Modified-Since : HTTP-date

Un esempio del campo è:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Se nessuno dei tag di entità corrisponde o se viene fornito "*" e non esiste alcuna entità corrente, il server non deve eseguire il metodo richiesto e deve restituire una risposta 412 (Precondizione non riuscita).

If-None-Match

Il campo di intestazione della richiesta If-None-Match viene utilizzato con un metodo per renderlo condizionale. Questa intestazione richiede al server di eseguire il metodo richiesto solo se uno dei valori forniti in questo tag corrisponde ai tag di entità dati rappresentati daETag. La sintassi generale è:

If-None-Match : entity-tag

Un asterisco (*) corrisponde a qualsiasi entità e la transazione continua solo se l'entità non esiste. Di seguito sono riportati i possibili esempi:

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

If-Range

Il campo If-Range request-header può essere utilizzato con un GET condizionale per richiedere solo la parte dell'entità che manca, se non è stata modificata, e l'intera entità se è stata modificata. La sintassi generale è la seguente:

If-Range : entity-tag | HTTP-date

È possibile utilizzare un tag di entità o una data per identificare l'entità parziale già ricevuta. Per esempio:

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

Qui se il documento non è stato modificato dalla data specificata, il server restituisce l'intervallo di byte dato dall'intestazione Range, altrimenti restituisce tutto il nuovo documento.

If-Unmodified-Since

Il campo If-Unmodified-Since dell'intestazione della richiesta viene utilizzato con un metodo per renderlo condizionale. La sintassi generale è:

If-Unmodified-Since : HTTP-date

Se la risorsa richiesta non è stata modificata dall'ora specificata in questo campo, il server dovrebbe eseguire l'operazione richiesta come se l'intestazione If-Unmodified-Since non fosse presente. Per esempio:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Se la richiesta risulta in qualcosa di diverso da uno stato 2xx o 412, l' intestazione If-Unmodified-Since deve essere ignorata.

Max-avanti

Il campo dell'intestazione della richiesta Max-Forwards fornisce un meccanismo con i metodi TRACE e OPTIONS per limitare il numero di proxy o gateway che possono inoltrare la richiesta al successivo server in entrata. Ecco la sintassi generale:

Max-Forwards : n

Il valore Max-Forward è un numero intero decimale che indica il numero rimanente di volte in cui questo messaggio di richiesta può essere inoltrato. Questo è utile per il debug con il metodo TRACE, evitando cicli infiniti. Per esempio:

Max-Forwards : 5

Il campo di intestazione Max-Forwards può essere ignorato per tutti gli altri metodi definiti nella specifica HTTP.

Autorizzazione proxy

Il campo dell'intestazione della richiesta di autorizzazione del proxy consente al client di identificare se stesso (o il suo utente) in un proxy che richiede l'autenticazione. Ecco la sintassi generale:

Proxy-Authorization : credentials

Il valore del campo Proxy-Authorization consiste in credenziali contenenti le informazioni di autenticazione dell'agente utente per il proxy e / o l'ambito della risorsa richiesta.

Gamma

Il campo Intestazione richiesta intervallo specifica gli intervalli parziali del contenuto richiesto dal documento. La sintassi generale è:

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

Il valore di posizione del primo byte in una specifica di intervallo di byte fornisce l'offset di byte del primo byte in un intervallo. Il valore last-byte-pos fornisce l'offset di byte dell'ultimo byte nell'intervallo; ovvero, le posizioni dei byte specificate sono inclusive. È possibile specificare un'unità byte come byte. Gli offset di byte iniziano da zero. Alcuni semplici esempi sono i seguenti:

- The first 500 bytes 
Range: bytes=0-499

- The second 500 bytes
Range: bytes=500-999

- The final 500 bytes
Range: bytes=-500

- The first and last bytes only
Range: bytes=0-0,-1

È possibile elencare più intervalli, separati da virgole. Se manca la prima cifra negli intervalli di byte separati da virgole, si presume che l'intervallo conti dalla fine del documento. Se manca la seconda cifra, l'intervallo è il byte n alla fine del documento.

Referente

Il campo Referer request-header consente al client di specificare l'indirizzo (URI) della risorsa da cui è stato richiesto l'URL. La sintassi generale è la seguente:

Referer : absoluteURI | relativeURI

Di seguito è riportato un semplice esempio:

Referer: http://www.tutorialspoint.org/http/index.htm

Se il valore del campo è un URI relativo, deve essere interpretato rispetto all'URI della richiesta .

TE

Il campo di intestazione della richiesta TE indica quale codifica di trasferimento di estensione è disposto ad accettare nella risposta e se è disposto o meno ad accettare campi rimorchio in una codifica di trasferimento a blocchi . Di seguito è riportata la sintassi generale:

TE   : t-codings

La presenza della parola chiave "trailer" indica che il client è disposto ad accettare campi trailer in una codifica di trasferimento a blocchi ed è specificata in uno dei modi:

TE: deflate
TE:
TE: trailers, deflate;q=0.5

Se il valore del campo TE è vuoto o se non è presente alcun campo TE, viene suddivisa in blocchi solo la codifica di trasferimento . Un messaggio senza codifica di trasferimento è sempre accettabile.

User-Agent

L'User-Agent request-header campo contiene le informazioni relative al programma utente generato la richiesta. Di seguito è riportata la sintassi generale:

User-Agent : product | comment

Esempio:

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Intestazioni di risposta del server

Accetta intervalli

Il campo di intestazione della risposta Accept-Ranges consente al server di indicare l'accettazione delle richieste di intervallo per una risorsa. La sintassi generale è:

Accept-Ranges  : range-unit | none

Ad esempio, un server che accetta richieste con intervallo di byte può inviare:

Accept-Ranges: bytes

I server che non accettano alcun tipo di richiesta di intervallo per una risorsa possono inviare:

Accept-Ranges: none

Questo consiglierà al client di non tentare una richiesta di intervallo.

Età

Il campo Age response-header trasmette la stima del mittente del tempo trascorso da quando la risposta (o la sua riconvalida) è stata generata sul server di origine. La sintassi generale è:

Age : delta-seconds

I valori di età sono numeri interi decimali non negativi, che rappresentano il tempo in secondi. Di seguito è riportato un semplice esempio:

Age: 1030

Un server HTTP / 1.1 che include una cache deve includere un campo di intestazione Age in ogni risposta generata dalla propria cache.

ETag

Il campo di intestazione della risposta ETag fornisce il valore corrente del tag di entità per la variante richiesta. La sintassi generale è:

ETag :  entity-tag

Alcuni semplici esempi:

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

Posizione

Il campo di intestazione della risposta della posizione viene utilizzato per reindirizzare il destinatario a una posizione diversa dall'URI della richiesta per il completamento. La sintassi generale è:

Location : absoluteURI

Di seguito è riportato un semplice esempio:

Location: http://www.tutorialspoint.org/http/index.htm

Il campo di intestazione Content-Location è diverso da Location in quanto Content-Location identifica la posizione originale dell'entità racchiusa nella richiesta.

Proxy-Authenticate

Il campo dell'intestazione della risposta con autenticazione proxy deve essere incluso come parte di una risposta 407 (autenticazione proxy richiesta). La sintassi generale è:

Proxy-Authenticate  : challenge

Riprova dopo

Il campo Retry-After response-header può essere utilizzato con una risposta 503 (Servizio non disponibile) per indicare per quanto tempo il servizio dovrebbe essere non disponibile per il client richiedente. La sintassi generale è:

Retry-After : HTTP-date | delta-seconds

Esempi:

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

In quest'ultimo esempio, il ritardo è di 2 minuti.

server

Il campo dell'intestazione della risposta del server contiene informazioni sul software utilizzato dal server di origine per gestire la richiesta. La sintassi generale è:

Server : product | comment

Di seguito è riportato un semplice esempio:

Server: Apache/2.2.14 (Win32)

Se la risposta viene inoltrata tramite un proxy, l'applicazione proxy non deve modificare l'intestazione della risposta del server.

Set-Cookie

Il campo Set-Cookie response-header contiene una coppia di informazioni nome / valore da conservare per questo URL. La sintassi generale è:

Set-Cookie: NAME=VALUE; OPTIONS

L'intestazione della risposta Set-Cookie comprende il token Set-Cookie, seguito da un elenco separato da virgole di uno o più cookie. Ecco i possibili valori che puoi specificare come opzioni:

SN	Opzioni e descrizione
1	Comment=comment Questa opzione può essere utilizzata per specificare qualsiasi commento associato al cookie.
2	Domain=domain L'attributo Domain specifica il dominio per il quale il cookie è valido.
3	Expires=Date-time La data in cui scadrà il cookie. Se è vuoto, il cookie scadrà quando il visitatore chiude il browser.
4	Path=path L'attributo Path specifica il sottoinsieme di URL a cui si applica questo cookie.
5	Secure Indica all'agente utente di restituire il cookie solo con una connessione sicura.

Di seguito è riportato un esempio di una semplice intestazione di cookie generata dal server:

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Variare

Il campo Vary response-header specifica che l'entità ha più origini e può quindi variare in base all'elenco specificato di intestazioni di richiesta. Di seguito è riportata la sintassi generale:

Vary : field-name

È possibile specificare più intestazioni separate da virgole e un valore di asterisco "*" segnala che i parametri non specificati non sono limitati alle intestazioni della richiesta. Di seguito è riportato un semplice esempio:

Vary: Accept-Language, Accept-Encoding

Qui i nomi dei campi non fanno distinzione tra maiuscole e minuscole.

WWW-Authenticate

Il campo dell'intestazione della risposta di autenticazione WWW deve essere incluso nei messaggi di risposta 401 (non autorizzati). Il valore del campo è costituito da almeno una sfida che indica gli schemi di autenticazione e i parametri applicabili all'URI della richiesta. La sintassi generale è:

WWW-Authenticate : challenge

Il valore del campo WWW-Authenticate potrebbe contenere più di una sfida, o se viene fornito più di un campo di intestazione WWW-Authenticate, il contenuto di una sfida stessa può contenere un elenco separato da virgole di parametri di autenticazione. Di seguito è riportato un semplice esempio:

WWW-Authenticate: BASIC realm="Admin"

Intestazioni di entità

permettere

Il campo Consenti intestazione entità elenca l'insieme di metodi supportati dalla risorsa identificata dall'URI della richiesta. La sintassi generale è:

Allow : Method

È possibile specificare più metodi separati da virgole. Di seguito è riportato un semplice esempio:

Allow: GET, HEAD, PUT

Questo campo non può impedire a un client di provare altri metodi.

Codifica dei contenuti

Il campo Content-Encoding entity-header viene utilizzato come modificatore del tipo di media. La sintassi generale è:

Content-Encoding : content-coding

La codifica del contenuto è una caratteristica dell'entità identificata dal Request-URI. Di seguito è riportato un semplice esempio:

Content-Encoding: gzip

Se la codifica del contenuto di un'entità in un messaggio di richiesta non è accettabile per il server di origine, il server deve rispondere con un codice di stato 415 (tipo di supporto non supportato).

Content-Language

Il campo Content-Language entity-header descrive le lingue naturali del pubblico previsto per l'entità inclusa. Di seguito è riportata la sintassi generale:

Content-Language : language-tag

È possibile che vengano elencate più lingue per i contenuti destinati a più segmenti di pubblico. Di seguito è riportato un semplice esempio:

Content-Language: mi, en

Lo scopo principale di Content-Language è consentire a un utente di identificare e differenziare le entità in base alla lingua preferita dell'utente.

Lunghezza del contenuto

Il campo Content-Length entity-header indica la dimensione del corpo-entità, in numero decimale di OCTET, inviato al destinatario o, nel caso del metodo HEAD, la dimensione del corpo-entità che sarebbe stato inviato, se la richiesta fosse stata un GET. La sintassi generale è:

Content-Length : DIGITS

Di seguito è riportato un semplice esempio:

Content-Length: 3495

Qualsiasi Content-Length maggiore o uguale a zero è un valore valido.

Content-Location

Il campo Content-Location entity-header può essere utilizzato per fornire la posizione della risorsa per l'entità racchiusa nel messaggio quando tale entità è accessibile da una posizione separata dall'URI della risorsa richiesta. La sintassi generale è:

Content-Location:  absoluteURI | relativeURI

Di seguito è riportato un semplice esempio:

Content-Location: http://www.tutorialspoint.org/http/index.htm

Il valore di Content-Location definisce anche l'URI di base per l'entità.

Content-MD5

Il campo Content-MD5 entity-header può essere utilizzato per fornire un digest MD5 dell'entità per verificare l'integrità del messaggio al momento della ricezione. La sintassi generale è:

Content-MD5  : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

Di seguito è riportato un semplice esempio:

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

Il digest MD5 viene calcolato in base al contenuto del corpo dell'entità, inclusa qualsiasi codifica del contenuto che è stata applicata, ma non include alcuna codifica di trasferimento applicata al corpo del messaggio.

Gamma di contenuti

Il campo Intestazione entità intervallo contenuto viene inviato con un corpo entità parziale per specificare dove deve essere applicato il corpo parziale nel corpo entità completo. La sintassi generale è:

Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos

Esempi di valori byte-content-range-spec, supponendo che l'entità contenga un totale di 1234 byte:

- The first 500 bytes:
Content-Range : bytes 0-499/1234

- The second 500 bytes:
Content-Range : bytes 500-999/1234

- All except for the first 500 bytes:
Content-Range : bytes 500-1233/1234

- The last 500 bytes:
Content-Range : bytes 734-1233/1234

Quando un messaggio HTTP include il contenuto di un singolo intervallo, questo contenuto viene trasmesso con un'intestazione Content-Range e un'intestazione Content-Length che mostra il numero di byte effettivamente trasferiti. Per 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

Tipo di contenuto

Il campo Content-Type entity-header indica il tipo di media del corpo dell'entità inviato al destinatario o, nel caso del metodo HEAD, il tipo di media che sarebbe stato inviato, se la richiesta fosse stata un GET. La sintassi generale è:

Content-Type : media-type

Di seguito è riportato un esempio:

Content-Type: text/html; charset=ISO-8859-4

Scade

Il campo Expires entity-header fornisce la data / ora dopo la quale la risposta è considerata obsoleta. La sintassi generale è:

Expires : HTTP-date

Di seguito è riportato un esempio:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Ultima modifica

Il campo Intestazione entità ultima modifica indica la data e l'ora in cui il server di origine ritiene che la variante sia stata modificata l'ultima volta. La sintassi generale è:

Last-Modified: HTTP-date

Di seguito è riportato un esempio:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT