5. Definizioni dei Campi di Intestazione (Header Field Definitions)

Questa sezione definisce la sintassi e la semantica dei campi di intestazione HTTP/1.1 relativi al caching.

5.1. Age

Il campo di intestazione "Age" trasmette la stima del mittente della quantità di tempo trascorso dalla generazione o validazione riuscita della risposta al server di origine. I valori Age sono calcolati come specificato nella Sezione 4.2.3.

Age = delta-seconds

Il valore del campo Age è un intero non negativo che rappresenta il tempo in secondi (vedere Sezione 1.2.1).

La presenza di un campo di intestazione Age implica che la risposta non è stata generata o validata dal server di origine per questa richiesta. Tuttavia, l'assenza di un campo di intestazione Age non implica che l'origine sia stata contattata, poiché la risposta potrebbe essere stata ricevuta da una cache HTTP/1.0 che non implementa Age.

5.2. Cache-Control

Il campo di intestazione "Cache-Control" viene utilizzato per specificare direttive per le cache lungo la catena richiesta/risposta. Tali direttive di cache sono unidirezionali nel senso che la presenza di una direttiva in una richiesta non implica che la stessa direttiva debba essere fornita nella risposta.

Una cache DEVE obbedire ai requisiti delle direttive Cache-Control definite in questa sezione. Vedere la Sezione 5.2.3 per informazioni su come vengono gestite le direttive Cache-Control definite altrove.

Nota: Alcune cache HTTP/1.0 potrebbero non implementare Cache-Control.

Un proxy, indipendentemente dal fatto che implementi o meno una cache, DEVE passare le direttive di cache nei messaggi inoltrati, indipendentemente dalla loro importanza per quell'applicazione, poiché le direttive potrebbero essere applicabili a tutti i destinatari lungo la catena richiesta/risposta. Non è possibile indirizzare una direttiva a una cache specifica.

Le direttive di cache sono identificate da un token, da confrontare senza distinzione tra maiuscole e minuscole, e hanno un argomento opzionale che può utilizzare sia la sintassi token che quoted-string. Per le direttive definite di seguito che definiscono argomenti, i destinatari dovrebbero accettare entrambe le forme, anche se una è documentata come preferita. Per qualsiasi direttiva non definita da questa specifica, un destinatario DEVE accettare entrambe le forme.

Cache-Control   = 1#cache-directive

cache-directive = token [ "=" ( token / quoted-string ) ]

Per le direttive di cache definite di seguito, nessun argomento è definito (né consentito) se non diversamente indicato.

5.2.1. Direttive Cache-Control di Richiesta (Request Cache-Control Directives)

5.2.1.1. max-age

Sintassi dell'argomento:

delta-seconds (vedere Sezione 1.2.1)

La direttiva di richiesta "max-age" indica che il client non è disposto ad accettare una risposta la cui età è maggiore del numero di secondi specificato. A meno che non sia presente anche la direttiva di richiesta max-stale, il client non è disposto ad accettare una risposta obsoleta.

Questa direttiva utilizza la forma token della sintassi dell'argomento: ad es., 'max-age=5' e non 'max-age="5"'. Un mittente NON DOVREBBE generare la forma quoted-string.

5.2.1.2. max-stale

Sintassi dell'argomento:

delta-seconds (vedere Sezione 1.2.1)

La direttiva di richiesta "max-stale" indica che il client è disposto ad accettare una risposta che ha superato la sua vita di freschezza. Se a max-stale viene assegnato un valore, allora il client è disposto ad accettare una risposta che ha superato la sua vita di freschezza di non più del numero di secondi specificato. Se nessun valore viene assegnato a max-stale, allora il client è disposto ad accettare una risposta obsoleta di qualsiasi età.

Questa direttiva utilizza la forma token della sintassi dell'argomento: ad es., 'max-stale=10' e non 'max-stale="10"'. Un mittente NON DOVREBBE generare la forma quoted-string.

5.2.1.3. min-fresh

Sintassi dell'argomento:

delta-seconds (vedere Sezione 1.2.1)

La direttiva di richiesta "min-fresh" indica che il client è disposto ad accettare una risposta la cui vita di freschezza non è inferiore alla sua età attuale più il tempo specificato in secondi. Cioè, il client vuole una risposta che rimarrà fresca per almeno il numero di secondi specificato.

Questa direttiva utilizza la forma token della sintassi dell'argomento: ad es., 'min-fresh=20' e non 'min-fresh="20"'. Un mittente NON DOVREBBE generare la forma quoted-string.

5.2.1.4. no-cache

La direttiva di richiesta "no-cache" indica che una cache NON DEVE utilizzare una risposta memorizzata per soddisfare la richiesta senza una validazione riuscita sul server di origine.

5.2.1.5. no-store

La direttiva di richiesta "no-store" indica che una cache NON DEVE memorizzare alcuna parte di questa richiesta o di qualsiasi risposta ad essa. Questa direttiva si applica sia alle cache private che a quelle condivise. "NON DEVE memorizzare" in questo contesto significa che la cache NON DEVE memorizzare intenzionalmente le informazioni in memoria non volatile e DEVE fare un tentativo di buona fede per rimuovere le informazioni dalla memoria volatile il più rapidamente possibile dopo averle inoltrate.

Questa direttiva NON È un meccanismo affidabile o sufficiente per garantire la privacy. In particolare, le cache dannose o compromesse potrebbero non riconoscere o obbedire a questa direttiva, e le reti di comunicazione potrebbero essere vulnerabili all'intercettazione.

Si noti che se una richiesta contenente questa direttiva viene soddisfatta da una cache, la direttiva di richiesta no-store non si applica alla risposta già memorizzata.

5.2.1.6. no-transform

La direttiva di richiesta "no-transform" indica che un intermediario (indipendentemente dal fatto che implementi o meno una cache) NON DEVE trasformare il payload, come definito nella Sezione 5.7.2 di [RFC7230].

5.2.1.7. only-if-cached

La direttiva di richiesta "only-if-cached" indica che il client desidera ottenere solo una risposta memorizzata. Se riceve questa direttiva, una cache DOVREBBE rispondere utilizzando una risposta memorizzata coerente con gli altri vincoli della richiesta, o rispondere con un codice di stato 504 (Gateway Timeout). Se un gruppo di cache viene gestito come un sistema unificato con una buona connettività interna, una cache membro PUÒ inoltrare tale richiesta all'interno di quel gruppo di cache.

5.2.2. Direttive Cache-Control di Risposta (Response Cache-Control Directives)

5.2.2.1. must-revalidate

La direttiva di risposta "must-revalidate" indica che una volta diventata obsoleta, una cache NON DEVE utilizzare la risposta per soddisfare richieste successive senza una validazione riuscita sul server di origine.

La direttiva must-revalidate è necessaria per supportare l'operazione affidabile di determinate funzionalità del protocollo. In tutte le circostanze una cache DEVE obbedire alla direttiva must-revalidate; in particolare, se una cache non può raggiungere il server di origine per qualsiasi motivo, DEVE generare una risposta 504 (Gateway Timeout).

La direttiva must-revalidate dovrebbe essere utilizzata dai server se e solo se il mancato convalida di una richiesta sulla rappresentazione potrebbe risultare in un'operazione errata, come una transazione finanziaria eseguita silenziosamente.

5.2.2.2. no-cache

Sintassi dell'argomento:

#field-name

La direttiva di risposta "no-cache" indica che la risposta NON DEVE essere utilizzata per soddisfare una richiesta successiva senza una validazione riuscita sul server di origine. Ciò consente a un server di origine di impedire a una cache di utilizzarla per soddisfare una richiesta senza contattarlo, anche dalle cache che sono state configurate per inviare risposte obsolete.

Se la direttiva di risposta no-cache specifica uno o più nomi di campo, allora una cache PUÒ utilizzare la risposta per soddisfare una richiesta successiva, soggetta a qualsiasi altra restrizione sul caching. Tuttavia, qualsiasi campo di intestazione nella risposta che ha i nomi di campo elencati NON DEVE essere inviato nella risposta a una richiesta successiva senza una riconvalida riuscita con il server di origine. Ciò consente a un server di origine di impedire il riutilizzo di determinati campi di intestazione in una risposta, pur consentendo il caching del resto della risposta.

I nomi di campo forniti non sono limitati all'insieme di campi di intestazione definiti da questa specifica. I nomi di campo non fanno distinzione tra maiuscole e minuscole.

Questa direttiva utilizza la forma quoted-string della sintassi dell'argomento. Un mittente NON DOVREBBE generare la forma token (anche se le virgolette sembrano non essere necessarie per elenchi a voce singola).

Nota: Sebbene sia stata retroportata a molte implementazioni, alcune cache HTTP/1.0 non riconoscono o non obbediscono a questa direttiva. Inoltre, la direttiva di risposta no-cache con nomi di campo viene generalmente trattata dalle cache come se fosse stata ricevuta una direttiva no-cache non qualificata; cioè, il trattamento speciale della forma qualificata non è ampiamente implementato.

5.2.2.3. no-store

La direttiva di risposta "no-store" indica che una cache NON DEVE memorizzare alcuna parte della richiesta immediata o della risposta. Questa direttiva si applica sia alle cache private che a quelle condivise. "NON DEVE memorizzare" in questo contesto significa che la cache NON DEVE memorizzare intenzionalmente le informazioni in memoria non volatile e DEVE fare un tentativo di buona fede per rimuovere le informazioni dalla memoria volatile il più rapidamente possibile dopo averle inoltrate.

Questa direttiva NON È un meccanismo affidabile o sufficiente per garantire la privacy. In particolare, le cache dannose o compromesse potrebbero non riconoscere o obbedire a questa direttiva, e le reti di comunicazione potrebbero essere vulnerabili all'intercettazione.

5.2.2.4. no-transform

La direttiva di risposta "no-transform" indica che un intermediario (indipendentemente dal fatto che implementi o meno una cache) NON DEVE trasformare il payload, come definito nella Sezione 5.7.2 di [RFC7230].

5.2.2.5. public

La direttiva di risposta "public" indica che qualsiasi cache PUÒ memorizzare la risposta, anche se la risposta sarebbe normalmente non memorizzabile in cache o memorizzabile in cache solo all'interno di una cache privata. (Vedere la Sezione 3.2 per dettagli aggiuntivi relativi all'uso di public in risposta a una richiesta contenente Authorization, e la Sezione 3 per dettagli su come public influisce sulle risposte che normalmente non verrebbero memorizzate, a causa dei loro codici di stato non definiti come memorizzabili in cache per impostazione predefinita; vedere Sezione 4.2.2.)

5.2.2.6. private

Sintassi dell'argomento:

#field-name

La direttiva di risposta "private" indica che il messaggio di risposta è destinato a un singolo utente e NON DEVE essere memorizzato da una cache condivisa. Una cache privata PUÒ memorizzare la risposta e riutilizzarla per richieste successive, anche se la risposta sarebbe normalmente non memorizzabile in cache.

Se la direttiva di risposta private specifica uno o più nomi di campo, questo requisito è limitato ai valori di campo associati ai campi di intestazione di risposta elencati. Cioè, una cache condivisa NON DEVE memorizzare i nomi di campo specificati, mentre PUÒ memorizzare il resto del messaggio di risposta.

I nomi di campo forniti non sono limitati all'insieme di campi di intestazione definiti da questa specifica. I nomi di campo non fanno distinzione tra maiuscole e minuscole.

Questa direttiva utilizza la forma quoted-string della sintassi dell'argomento. Un mittente NON DOVREBBE generare la forma token (anche se le virgolette sembrano non essere necessarie per elenchi a voce singola).

Nota: Questo uso di "private" controlla solo dove la risposta può essere memorizzata; non può garantire la privacy del contenuto del messaggio. Inoltre, la direttiva di risposta private con nomi di campo viene generalmente trattata dalle cache come se fosse stata ricevuta una direttiva private non qualificata; cioè, il trattamento speciale della forma qualificata non è ampiamente implementato.

5.2.2.7. proxy-revalidate

La direttiva di risposta "proxy-revalidate" ha lo stesso significato della direttiva di risposta must-revalidate, tranne per il fatto che non si applica alle cache private.

5.2.2.8. max-age

Sintassi dell'argomento:

delta-seconds (vedere Sezione 1.2.1)

La direttiva di risposta "max-age" indica che la risposta deve essere considerata obsoleta dopo che la sua età è maggiore del numero di secondi specificato.

Questa direttiva utilizza la forma token della sintassi dell'argomento: ad es., 'max-age=5' e non 'max-age="5"'. Un mittente NON DOVREBBE generare la forma quoted-string.

5.2.2.9. s-maxage

Sintassi dell'argomento:

delta-seconds (vedere Sezione 1.2.1)

La direttiva di risposta "s-maxage" indica che, nelle cache condivise, l'età massima specificata da questa direttiva sovrascrive l'età massima specificata dalla direttiva max-age o dal campo di intestazione Expires. La direttiva s-maxage implica anche la semantica della direttiva di risposta proxy-revalidate.

Questa direttiva utilizza la forma token della sintassi dell'argomento: ad es., 's-maxage=10' e non 's-maxage="10"'. Un mittente NON DOVREBBE generare la forma quoted-string.

5.2.3. Estensioni Cache-Control (Cache Control Extensions)

Il campo di intestazione Cache-Control può essere esteso attraverso l'uso di uno o più token di estensione cache, ciascuno con un valore opzionale. Una cache DEVE ignorare le direttive di cache non riconosciute.

Le estensioni informative (quelle che non richiedono un cambiamento nel comportamento della cache) possono essere aggiunte senza modificare la semantica di altre direttive.

Le estensioni comportamentali sono progettate per funzionare agendo come modificatori alla base esistente di direttive di cache. Vengono fornite sia la nuova direttiva che la vecchia direttiva, in modo che le applicazioni che non comprendono la nuova direttiva adotteranno per impostazione predefinita il comportamento specificato dalla vecchia direttiva, e quelle che comprendono la nuova direttiva la riconosceranno come modifica dei requisiti associati alla vecchia direttiva. In questo modo, è possibile apportare estensioni alle direttive di controllo della cache esistenti senza interrompere le cache distribuite.

Ad esempio, considerare una nuova direttiva di risposta ipotetica chiamata "community" che agisce come modificatore della direttiva private: oltre alle cache private, qualsiasi cache condivisa solo dai membri della comunità denominata è autorizzata a memorizzare in cache la risposta. Un server di origine che desidera consentire alla comunità UCI di utilizzare una risposta altrimenti privata nella loro cache condivisa potrebbe farlo includendo:

Cache-Control: private, community="UCI"

Una cache che riconosce tale estensione di cache comunitaria potrebbe ampliare il suo comportamento in conformità con tale estensione. Una cache che non riconosce l'estensione di cache comunitaria la ignorerebbe e aderebbe alla direttiva private.

5.3. Expires

Il campo di intestazione "Expires" fornisce la data/ora dopo la quale la risposta è considerata obsoleta. Vedere la Sezione 4.2 per ulteriori discussioni sul modello di freschezza.

La presenza di un campo Expires non implica che la risorsa originale cambierà o cesserà di esistere in quel momento, prima o dopo.

Il valore Expires è un timestamp HTTP-date, come definito nella Sezione 7.1.1.1 di [RFC7231].

Expires = HTTP-date

Ad esempio:

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

Un destinatario di cache DEVE interpretare i formati di data non validi, in particolare il valore "0", come rappresentanti un momento nel passato (cioè, "già scaduto").

Se una risposta include un campo Cache-Control con la direttiva max-age (Sezione 5.2.2.8), un destinatario DEVE ignorare il campo Expires. Allo stesso modo, se una risposta include la direttiva s-maxage (Sezione 5.2.2.9), un destinatario di cache condivisa DEVE ignorare il campo Expires. In entrambi questi casi, il valore in Expires è destinato solo ai destinatari che non hanno ancora implementato il campo Cache-Control.

Un server di origine senza orologio NON DEVE generare un campo Expires a meno che il suo valore rappresenti un momento fisso nel passato (sempre scaduto) o il suo valore sia stato associato alla risorsa da un sistema o utente con un orologio affidabile.

Storicamente, HTTP richiedeva che il valore del campo Expires non fosse superiore a un anno nel futuro. Sebbene vite di freschezza più lunghe non siano più vietate, è stato dimostrato che valori estremamente grandi causano problemi (ad es., overflow di orologio dovuti all'uso di interi a 32 bit per i valori temporali), e molte cache espelleranno una risposta molto prima di allora.

5.4. Pragma

Il campo di intestazione "Pragma" consente la retrocompatibilità con le cache HTTP/1.0, in modo che i client possano specificare una richiesta "no-cache" che comprenderanno (poiché Cache-Control non è stato definito fino a HTTP/1.1). Quando il campo di intestazione Cache-Control è presente e compreso anche in una richiesta, Pragma viene ignorato.

In HTTP/1.0, Pragma era definito come campo estensibile per direttive specifiche dell'implementazione per i destinatari. Questa specifica depreca tali estensioni per migliorare l'interoperabilità.

Pragma           = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]

Quando il campo di intestazione Cache-Control non è presente in una richiesta, le cache DEVONO considerare la direttiva pragma-directive di richiesta no-cache come avente lo stesso effetto di "Cache-Control: no-cache" (vedere Sezione 5.2.1).

Quando si invia una richiesta no-cache, un client dovrebbe includere sia le direttive pragma che cache-control, a meno che Cache-Control: no-cache non venga intenzionalmente omesso per indirizzare altre direttive di risposta Cache-Control alle cache HTTP/1.1. Ad esempio:

GET / HTTP/1.1
Host: www.example.com
Cache-Control: max-age=30
Pragma: no-cache

vincolerà le cache HTTP/1.1 a servire una risposta non più vecchia di 30 secondi, impedendo al contempo alle implementazioni che non comprendono Cache-Control di servire una risposta memorizzata in cache.

Nota: Poiché il significato di "Pragma: no-cache" nelle risposte non è specificato, non può fornire un sostituto affidabile per "Cache-Control: no-cache" per esse.

5.5. Warning

Il campo di intestazione "Warning" viene utilizzato per trasportare informazioni aggiuntive sullo stato o sulla trasformazione di un messaggio che potrebbero non essere riflesse nel codice di stato. Queste informazioni vengono tipicamente utilizzate per avvisare di possibili inesattezze introdotte dalle operazioni di caching o dalle trasformazioni applicate al payload del messaggio.

Gli avvisi possono essere utilizzati per altri scopi, sia correlati alla cache che altrimenti. L'uso di un avviso, anziché di un codice di stato di errore, distingue queste risposte dai veri fallimenti.

I campi di intestazione Warning possono in generale essere applicati a qualsiasi messaggio, tuttavia alcuni codici di avviso sono specifici per le cache e possono essere applicati solo ai messaggi di risposta.

Warning       = 1#warning-value

warning-value = warn-code SP warn-agent SP warn-text
                                      [ SP warn-date ]

warn-code  = 3DIGIT
warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-text  = quoted-string
warn-date  = DQUOTE HTTP-date DQUOTE

È possibile generare più avvisi in una risposta (dal server di origine o da una cache), inclusi più avvisi con lo stesso numero di codice di avviso che differiscono solo nel testo di avviso.

Un user agent che riceve uno o più campi di intestazione Warning DOVREBBE informare l'utente di quanti più possibile, nell'ordine in cui appaiono nella risposta. I mittenti che generano più campi di intestazione Warning sono incoraggiati a ordinarli tenendo presente questo comportamento dell'user agent. Un mittente che genera nuovi campi di intestazione Warning DEVE aggiungerli dopo eventuali campi di intestazione Warning esistenti.

Gli avvisi vengono assegnati codici di avviso a tre cifre. La prima cifra indica se l'avviso deve essere eliminato da una risposta memorizzata dopo la validazione:

• I codici di avviso 1xx descrivono lo stato di freschezza o validazione della risposta e pertanto DEVONO essere eliminati da una cache dopo la validazione. Possono essere generati solo da una cache durante la validazione di una voce in cache e NON DEVONO essere generati in nessun'altra situazione.

• I codici di avviso 2xx descrivono un aspetto della rappresentazione che non viene rettificato da una validazione (ad esempio, una compressione con perdita della rappresentazione) e NON DEVONO essere eliminati da una cache dopo la validazione, a meno che non venga inviata una risposta completa, nel qual caso DEVONO esserlo.

Se un mittente genera uno o più codici di avviso 1xx in un messaggio da inviare a un destinatario noto per implementare solo HTTP/1.0, il mittente DEVE includere in ogni valore di avviso corrispondente una data di avviso che corrisponda al campo di intestazione Date nel messaggio. Ad esempio:

HTTP/1.1 200 OK
Date: Sat, 25 Aug 2012 23:34:45 GMT
Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"

Gli avvisi hanno un testo di avviso accompagnante che descrive l'errore, ad es., per la registrazione. È solo consultivo e il suo contenuto non influisce sull'interpretazione del codice di avviso.

Se un destinatario che utilizza, valuta o visualizza campi di intestazione Warning riceve una data di avviso diversa dal valore Date nello stesso messaggio, il destinatario DEVE escludere il valore di avviso contenente quella data di avviso prima di memorizzare, inoltrare o utilizzare il messaggio. Ciò consente ai destinatari di escludere i valori di avviso che sono stati trattenuti in modo improprio dopo una validazione della cache. Se tutti i valori di avviso sono esclusi, il destinatario DEVE escludere anche il campo di intestazione Warning.

I seguenti codici di avviso sono definiti da questa specifica, ciascuno con un testo di avviso raccomandato in inglese e una descrizione del suo significato. La procedura per definire codici di avviso aggiuntivi è descritta nella Sezione 7.2.1.

5.5.1. Warning: 110 - "Response is Stale"

Una cache DOVREBBE generare questo ogni volta che la risposta inviata è obsoleta.

5.5.2. Warning: 111 - "Revalidation Failed"

Una cache DOVREBBE generare questo quando invia una risposta obsoleta perché un tentativo di convalidare la risposta è fallito, a causa dell'impossibilità di raggiungere il server.

5.5.3. Warning: 112 - "Disconnected Operation"

Una cache DOVREBBE generare questo se è intenzionalmente disconnessa dal resto della rete per un periodo di tempo.

5.5.4. Warning: 113 - "Heuristic Expiration"

Una cache DOVREBBE generare questo se ha euristicamente scelto una vita di freschezza maggiore di 24 ore e l'età della risposta è maggiore di 24 ore.

5.5.5. Warning: 199 - "Miscellaneous Warning"

Il testo di avviso può includere informazioni arbitrarie da presentare a un utente umano o registrare. Un sistema che riceve questo avviso NON DEVE intraprendere alcuna azione automatizzata, oltre a presentare l'avviso all'utente.

5.5.6. Warning: 214 - "Transformation Applied"

Questo codice di avviso DEVE essere aggiunto da un proxy se applica una trasformazione alla rappresentazione, come modificare il content-coding, il media-type o modificare i dati di rappresentazione, a meno che questo codice di avviso non appaia già nella risposta.

5.5.7. Warning: 299 - "Miscellaneous Persistent Warning"

Il testo di avviso può includere informazioni arbitrarie da presentare a un utente umano o registrare. Un sistema che riceve questo avviso NON DEVE intraprendere alcuna azione automatizzata.