5. Field Definitions (Definizioni dei campi)

Questa sezione definisce la sintassi e la semantica dei campi HTTP relativi alla memorizzazione nella cache.

5.1 Age

Il campo di intestazione di risposta "Age" trasmette la stima del mittente del tempo trascorso da quando la risposta è stata generata o validata con successo presso il server di origine. Il valore Age è calcolato 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 la sezione 1.2.2).

Sebbene sia definito come un campo di intestazione singleton, una cache che incontra un messaggio con un valore del campo Age basato su elenco dovrebbe (SHOULD) utilizzare il primo membro del valore del campo, scartando i membri successivi.

Se il valore del campo (dopo aver scartato altri membri, come sopra) non è valido (ad esempio, contiene qualcosa di diverso da un intero non negativo), una cache dovrebbe (SHOULD) ignorare il campo.

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, la mancanza di un campo di intestazione Age non implica che il server di origine sia stato contattato.

5.2 Cache-Control

Il campo di intestazione "Cache-Control" viene utilizzato per elencare le direttive per le cache lungo la catena richiesta/risposta. Le direttive di cache sono unidirezionali nel senso che la presenza di una direttiva in una richiesta non implica che la stessa direttiva sia presente o copiata nella risposta.

Vedere la sezione 5.2.3 per informazioni su come vengono gestite le direttive Cache-Control definite altrove.

Un proxy, indipendentemente dal fatto che implementi o meno una cache, deve (MUST) trasmettere le direttive di cache nei messaggi inoltrati, indipendentemente dal loro significato per quell'applicazione, poiché le direttive potrebbero applicarsi 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 quella stringa tra virgolette. Per le direttive definite di seguito in cui è definito un argomento, i destinatari dovrebbero (SHOULD) accettare entrambe le forme, anche se è richiesta una forma specifica per la generazione.

Cache-Control   = #cache-directive

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

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

5.2.1 Request Directives (Direttive di richiesta)

Questa sezione definisce le direttive di richiesta della cache. Sono consultive; le cache possono (MAY) implementarle, ma non sono obbligate a farlo.

5.2.1.1 max-age

Sintassi dell'argomento:

delta-seconds (vedere la sezione 1.2.2)

La direttiva di richiesta max-age indica che il client preferisce una risposta la cui età è inferiore o uguale al numero di secondi specificato. A meno che non sia presente anche la direttiva di richiesta max-stale, il client non desidera ricevere una risposta obsoleta.

Questa direttiva utilizza la forma token della sintassi dell'argomento: ad esempio, 'max-age=5' non 'max-age="5"'. Un mittente non deve (MUST NOT) generare la forma stringa tra virgolette.

5.2.1.2 max-stale

Sintassi dell'argomento:

delta-seconds (vedere la sezione 1.2.2)

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

Questa direttiva utilizza la forma token della sintassi dell'argomento: ad esempio, 'max-stale=10' non 'max-stale="10"'. Un mittente non deve (MUST NOT) generare la forma stringa tra virgolette.

5.2.1.3 min-fresh

Sintassi dell'argomento:

delta-seconds (vedere la sezione 1.2.2)

La direttiva di richiesta min-fresh indica che il client preferisce una risposta la cui durata di vita di freschezza non sia inferiore alla sua età corrente più il numero di secondi specificato. Cioè, il client desidera una risposta che rimarrà fresca per almeno il numero di secondi specificato.

Questa direttiva utilizza la forma token della sintassi dell'argomento: ad esempio, 'min-fresh=20' non 'min-fresh="20"'. Un mittente non deve (MUST NOT) generare la forma stringa tra virgolette.

5.2.1.4 no-cache

La direttiva di richiesta no-cache indica che il client preferisce che le risposte memorizzate non vengano utilizzate per soddisfare la richiesta senza una validazione riuscita presso il server di origine.

5.2.1.5 no-store

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

Questa direttiva non è un meccanismo affidabile o sufficiente per garantire la privacy. In particolare, le cache malevole 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 il client sta chiedendo a un intermediario di evitare di trasformare il contenuto, come definito dalla sezione 7.7 di [HTTP].

5.2.1.7 only-if-cached

La direttiva di richiesta only-if-cached indica che il client desidera ottenere solo una risposta memorizzata. Una cache che rispetta questa direttiva di richiesta dovrebbe (SHOULD) rispondere con una risposta memorizzata coerente con gli altri vincoli della richiesta, o un codice di stato 504 (Gateway Timeout) al momento della ricezione.

5.2.2 Response Directives (Direttive di risposta)

Questa sezione definisce le direttive di risposta della cache. Le cache devono (MUST) obbedire alle direttive Cache-Control definite in questa sezione.

5.2.2.1 max-age

Sintassi dell'argomento:

delta-seconds (vedere la sezione 1.2.2)

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 esempio, 'max-age=5' non 'max-age="5"'. Un mittente non deve (MUST NOT) generare la forma stringa tra virgolette.

5.2.2.2 must-revalidate

La direttiva di risposta must-revalidate indica che una volta che la risposta è diventata obsoleta, una cache non deve (MUST NOT) riutilizzare quella risposta per soddisfare un'altra richiesta fino a quando non è stata validata con successo dal server di origine, come definito nella sezione 4.3.

La direttiva must-revalidate è necessaria per supportare il funzionamento affidabile di alcune funzionalità del protocollo. In tutte le circostanze una cache non deve (MUST NOT) ignorare la direttiva must-revalidate; in particolare, se una cache è disconnessa, la cache deve (MUST) generare una risposta di errore piuttosto che riutilizzare la risposta obsoleta. Il codice di stato generato dovrebbe (SHOULD) essere 504 (Gateway Timeout) a meno che un altro codice di stato di errore sia più applicabile.

I server dovrebbero (SHOULD) utilizzare la direttiva must-revalidate solo quando il fallimento della rivalidazione di una richiesta potrebbe causare un funzionamento errato (come una transazione finanziaria eseguita silenziosamente).

La direttiva must-revalidate consente anche a una cache condivisa di riutilizzare una risposta a una richiesta contenente un campo di intestazione Authorization (vedere la sezione 11.6.2 di [HTTP]), soggetta al requisito sopra riportato sulla rivalidazione (sezione 3.5).

5.2.2.3 must-understand

La direttiva di risposta must-understand limita la memorizzazione nella cache della risposta alle cache che comprendono e si conformano ai requisiti per il codice di stato di quella risposta.

Una risposta che contiene una direttiva must-understand dovrebbe (SHOULD) contenere anche una direttiva no-store. Quando una cache che implementa la direttiva must-understand riceve una risposta che la contiene, la cache dovrebbe (SHOULD) ignorare la direttiva no-store se comprende e implementa i requisiti di memorizzazione nella cache del codice di stato.

5.2.2.4 no-cache

Sintassi dell'argomento:

#field-name

La direttiva di risposta no-cache, nella sua forma non qualificata (senza argomento), indica che la risposta non deve (MUST NOT) essere utilizzata per soddisfare qualsiasi altra richiesta senza inoltrarla per la validazione e ricevere una risposta riuscita; vedere la sezione 4.3.

Ciò consente a un server di origine di impedire a una cache di utilizzare la risposta per soddisfare una richiesta senza contattarlo, anche da parte di cache configurate per inviare risposte obsolete.

La forma qualificata della direttiva di risposta no-cache, con un argomento che elenca uno o più nomi di campo, indica che una cache può (MAY) utilizzare la risposta per soddisfare una richiesta successiva, soggetta a qualsiasi altra restrizione sulla memorizzazione nella cache, se i campi di intestazione elencati sono esclusi dalla risposta successiva o la risposta successiva è stata rivalidata con successo con il server di origine (aggiornando o rimuovendo quei campi). Ciò consente a un server di origine di impedire il riutilizzo di alcuni campi di intestazione in una risposta, pur consentendo la memorizzazione nella cache 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 sono insensibili alle maiuscole.

Questa direttiva utilizza la forma stringa tra virgolette della sintassi dell'argomento. Un mittente non dovrebbe (SHOULD NOT) generare la forma token (anche se le virgolette non sembrano necessarie per gli elenchi a voce singola).

Nota: La forma qualificata della direttiva è spesso gestita dalle cache come se fosse stata ricevuta una direttiva no-cache non qualificata; cioè, la gestione speciale della forma qualificata non è ampiamente implementata.

5.2.2.5 no-store

La direttiva di risposta no-store indica che una cache non deve (MUST NOT) memorizzare alcuna parte della richiesta o risposta immediata e non deve (MUST NOT) utilizzare la risposta per soddisfare qualsiasi altra richiesta.

Questa direttiva si applica sia alle cache private che a quelle condivise. "MUST NOT store" in questo contesto significa che la cache non deve (MUST NOT) memorizzare intenzionalmente le informazioni in storage non volatile e deve (MUST) fare un tentativo di buona fede per rimuovere le informazioni dallo storage volatile il più rapidamente possibile dopo averle inoltrate.

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

Si noti che la direttiva di cache must-understand sovrascrive no-store in determinate circostanze; vedere la sezione 5.2.2.3.

5.2.2.6 no-transform

La direttiva di risposta no-transform indica che un intermediario (indipendentemente dal fatto che implementi o meno una cache) non deve (MUST NOT) trasformare il contenuto, come definito dalla sezione 7.7 di [HTTP].

5.2.2.7 private

Sintassi dell'argomento:

#field-name

La direttiva di risposta private non qualificata indica che una cache condivisa non deve (MUST NOT) memorizzare la risposta (cioè, la risposta è destinata a un singolo utente). Indica anche che una cache privata può (MAY) memorizzare la risposta, soggetta ai vincoli definiti nella sezione 3, anche se la risposta non sarebbe altrimenti euristicamente memorizzabile nella cache da una cache privata.

Se è presente una direttiva di risposta private qualificata (con un argomento che elenca uno o più nomi di campo), solo i campi di intestazione elencati sono limitati a un singolo utente: una cache condivisa non deve (MUST NOT) memorizzare i campi di intestazione elencati se sono presenti nella risposta originale, ma può (MAY) memorizzare il resto del messaggio di risposta senza quei campi di intestazione, soggetto ai vincoli definiti nella sezione 3.

I nomi di campo forniti non sono limitati all'insieme di campi di intestazione definiti da questa specifica. I nomi di campo sono insensibili alle maiuscole.

Questa direttiva utilizza la forma stringa tra virgolette della sintassi dell'argomento. Un mittente non dovrebbe (SHOULD NOT) generare la forma token (anche se le virgolette non sembrano necessarie per gli elenchi a voce singola).

Nota: Questo uso della parola "private" controlla solo dove la risposta può essere memorizzata; non può garantire la privacy del contenuto del messaggio. Inoltre, la forma qualificata della direttiva è spesso gestita dalle cache come se fosse stata ricevuta una direttiva private non qualificata; cioè, la gestione speciale della forma qualificata non è ampiamente implementata.

5.2.2.8 proxy-revalidate

La direttiva di risposta proxy-revalidate indica che una volta che la risposta è diventata obsoleta, una cache condivisa non deve (MUST NOT) riutilizzare quella risposta per soddisfare un'altra richiesta fino a quando non è stata validata con successo dal server di origine, come definito nella sezione 4.3. Questo è analogo a must-revalidate (sezione 5.2.2.2), tranne che proxy-revalidate non si applica alle cache private.

Si noti che proxy-revalidate da solo non implica che una risposta sia memorizzabile nella cache. Ad esempio, potrebbe essere combinato con la direttiva public (sezione 5.2.2.9) per consentire la memorizzazione nella cache di una risposta richiedendo solo alle cache condivise di rivalidare quando è obsoleta.

5.2.2.9 public

La direttiva di risposta public indica che una cache può (MAY) memorizzare la risposta anche se sarebbe altrimenti vietato, soggetto ai vincoli definiti nella sezione 3. In altre parole, public marca esplicitamente la risposta come memorizzabile nella cache. Ad esempio, public consente a una cache condivisa di riutilizzare una risposta a una richiesta contenente un campo di intestazione Authorization (sezione 3.5).

Si noti che non è necessario aggiungere la direttiva public a una risposta che è già memorizzabile nella cache secondo la sezione 3.

Se una risposta con una direttiva public non ha informazioni di freschezza esplicite, è euristicamente memorizzabile nella cache (sezione 4.2.2).

5.2.2.10 s-maxage

Sintassi dell'argomento:

delta-seconds (vedere la sezione 1.2.2)

La direttiva di risposta s-maxage indica che, per una cache condivisa, 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 incorpora la semantica della direttiva di risposta proxy-revalidate (sezione 5.2.2.8) per le cache condivise. Una cache condivisa non deve (MUST NOT) riutilizzare una risposta obsoleta con s-maxage per soddisfare un'altra richiesta fino a quando non è stata validata con successo dal server di origine, come definito nella sezione 4.3. Questa direttiva consente anche a una cache condivisa di riutilizzare una risposta a una richiesta contenente un campo di intestazione Authorization, soggetta ai requisiti sopra riportati sull'età massima e la rivalidazione (sezione 3.5).

Questa direttiva utilizza la forma token della sintassi dell'argomento: ad esempio, 's-maxage=10' non 's-maxage="10"'. Un mittente non deve (MUST NOT) generare la forma stringa tra virgolette.

5.2.3 Extension Directives (Direttive di estensione)

Il campo di intestazione Cache-Control può essere esteso mediante l'uso di una o più direttive di cache di estensione. Una cache deve (MUST) 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. Sia la nuova direttiva che la vecchia direttiva vengono fornite, in modo tale che le applicazioni che non comprendono la nuova direttiva utilizzeranno 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 cache esistenti senza interrompere le cache distribuite.

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

Cache-Control: private, community="UCI"

Le cache che riconoscono tale direttiva di cache community potrebbero ampliare il loro comportamento in conformità con tale estensione. Le cache che non riconoscono la direttiva di cache community la ignorerebbero e aderirebbero alla direttiva private.

Le nuove direttive di estensione dovrebbero considerare di definire:

• Cosa significa specificare la direttiva più volte,

• Quando l'argomento della direttiva è presente, cosa significa quando l'argomento è assente,

• Quando l'argomento della direttiva è richiesto, cosa significa quando l'argomento è mancante, e

• Se la direttiva è specifica per le richieste, specifica per le risposte o può essere utilizzata in entrambe.

5.2.4 Cache Directive Registry (Registro delle direttive di cache)

Il "Registro delle direttive di cache del protocollo di trasferimento ipertestuale (HTTP) (Hypertext Transfer Protocol (HTTP) Cache Directive Registry)" definisce lo spazio dei nomi per le direttive di cache. È stato creato ed è ora mantenuto presso https://www.iana.org/assignments/http-cache-directives.

Una registrazione deve (MUST) includere i seguenti campi:

• Nome della direttiva di cache

• Puntatore al testo della specifica

I valori da aggiungere a questo spazio dei nomi richiedono una revisione IETF (vedere la sezione 4.8 di [RFC8126]).

5.3 Expires

Il campo di intestazione di risposta "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 di intestazione Expires non implica che la risorsa originale cambierà o cesserà di esistere a, prima o dopo quel momento.

Il valore del campo Expires è un timestamp HTTP-date, come definito nella sezione 5.6.7 di [HTTP]. Per i requisiti di analisi specifici della cache, vedere anche la sezione 4.2.

Expires = HTTP-date

Ad esempio:

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

Un destinatario della cache deve (MUST) 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 di intestazione Cache-Control con la direttiva max-age (sezione 5.2.2.1), un destinatario deve (MUST) ignorare il campo di intestazione Expires. Allo stesso modo, se una risposta include la direttiva s-maxage (sezione 5.2.2.10), un destinatario di cache condivisa deve (MUST) ignorare il campo di intestazione Expires. In entrambi i casi, il valore in Expires è destinato solo ai destinatari che non hanno ancora implementato il campo di intestazione Cache-Control.

Un server di origine senza orologio (vedere la sezione 5.6.7 di [HTTP]) non deve (MUST NOT) generare un campo di intestazione Expires a meno che il suo valore non rappresenti un momento fisso nel passato (sempre scaduto) o il suo valore sia stato associato alla risorsa da un sistema con un orologio.

Storicamente, HTTP richiedeva che il valore del campo Expires non fosse superiore a un anno nel futuro. Sebbene durate di vita di freschezza più lunghe non siano più vietate, valori estremamente grandi hanno dimostrato di causare problemi (ad esempio, overflow dell'orologio dovuto all'uso di interi a 32 bit per i valori temporali), e molte cache evacueranno una risposta molto prima.

5.4 Pragma

Il campo di intestazione di richiesta "Pragma" è stato definito per le cache HTTP/1.0, in modo che i client potessero specificare una richiesta "no-cache" (poiché Cache-Control non è stato definito fino a HTTP/1.1).

Tuttavia, il supporto per Cache-Control è ora diffuso. Di conseguenza, questa specifica depreca Pragma.

Nota: Poiché il significato di "Pragma: no-cache" nelle risposte non è mai stato specificato, non fornisce un sostituto affidabile per "Cache-Control: no-cache" nelle risposte.

5.5 Warning

Il campo di intestazione "Warning" è stato utilizzato per trasportare informazioni aggiuntive sullo stato o la trasformazione di un messaggio che potrebbero non essere riflesse nel codice di stato. Questa specifica lo rende obsoleto, poiché non è ampiamente generato o mostrato agli utenti. Le informazioni che trasportava possono essere raccolte esaminando altri campi di intestazione, come Age.