3. Storing Responses in Caches (Memorizzazione delle risposte nelle cache)

Una cache non deve (MUST NOT) memorizzare una risposta a una richiesta a meno che non siano soddisfatte tutte le seguenti condizioni:

• Il metodo di richiesta è compreso dalla cache;

• Il codice di stato della risposta è finale (Final) (vedere la sezione 15 di [HTTP]);

• Se il codice di stato della risposta è 206 o 304, o è presente una direttiva di cache must-understand (vedere la sezione 5.2.2.3): la cache comprende il codice di stato della risposta;

• La direttiva di cache no-store non è presente nella risposta (vedere la sezione 5.2.2.5);

• Se la cache è condivisa: la direttiva di risposta private non è presente o consente alle cache condivise di memorizzare una risposta modificata (vedere la sezione 5.2.2.7);

• Se la cache è condivisa: il campo di intestazione Authorization (vedere la sezione 11.6.2 di [HTTP]) non è presente nella richiesta o una direttiva di risposta consente esplicitamente le cache condivise (vedere la sezione 3.5); e

• La risposta contiene almeno uno dei seguenti:

  • Una direttiva di risposta public (vedere la sezione 5.2.2.9);

  • Una direttiva di risposta private, se la cache non è condivisa (vedere la sezione 5.2.2.7);

  • Un campo di intestazione Expires (vedere la sezione 5.3);

  • Una direttiva di risposta max-age (vedere la sezione 5.2.2.1);

  • Se la cache è condivisa: una direttiva di risposta s-maxage (vedere la sezione 5.2.2.10);

  • Un'estensione di cache che consente la memorizzazione nella cache (vedere la sezione 5.2.3); o

  • Un codice di stato definito come euristicamente memorizzabile nella cache (Heuristically Cacheable) (vedere la sezione 4.2.2).

Si noti che le estensioni di cache possono sovrascrivere uno qualsiasi dei requisiti elencati sopra; vedere la sezione 5.2.3.

In questo contesto, una cache "comprende (Understood)" un metodo di richiesta o un codice di stato della risposta se la cache lo riconosce e implementa tutto il comportamento relativo alla cache specificato.

Si noti che, nel normale funzionamento, alcune cache non memorizzeranno risposte che non hanno né un validatore di cache (Cache Validator) né un tempo di scadenza esplicito, poiché tali risposte spesso non vale la pena memorizzare. Tuttavia, le cache non sono vietate dal memorizzare tali risposte.

3.1 Storing Header and Trailer Fields (Memorizzazione dei campi di intestazione e di coda)

Una cache deve (MUST) includere tutti i campi di intestazione della risposta ricevuti quando memorizza una risposta -- compresi i campi non riconosciuti; ciò garantisce che i nuovi campi di intestazione HTTP possano essere distribuiti con successo. Tuttavia, esistono le seguenti eccezioni:

• Il campo di intestazione Connection e i campi i cui nomi sono elencati in esso devono (MUST) essere rimossi prima di inoltrare i messaggi secondo la sezione 7.6.1 di [HTTP]. Ciò può (MAY) essere ottenuto rimuovendoli prima della memorizzazione.

• Allo stesso modo, la semantica di alcuni campi richiede di rimuoverli prima di inoltrare i messaggi, il che può (MAY) essere ottenuto rimuovendoli prima della memorizzazione; vedere la sezione 7.6.1 di [HTTP] per alcuni esempi.

• Le direttive di cache no-cache (sezione 5.2.2.4) e private (sezione 5.2.2.7) possono avere parametri che impediscono rispettivamente a tutte le cache e alle cache condivise di memorizzare i campi di intestazione.

• I campi di intestazione specifici del proxy che sono utilizzati da una cache quando inoltra le richieste non devono (MUST NOT) essere memorizzati a meno che la cache non incorpori l'identità del proxy nella chiave di cache. In pratica, questo è limitato a Proxy-Authenticate (sezione 11.7.1 di [HTTP]), Proxy-Authentication-Info (sezione 11.7.3 di [HTTP]) e Proxy-Authorization (sezione 11.7.2 di [HTTP]).

Una cache può (MAY) memorizzare i campi di coda (Trailer Fields) separatamente dai campi di intestazione o eliminarli. Le cache non devono (MUST NOT) combinare i campi di coda con i campi di intestazione.

3.2 Updating Stored Header Fields (Aggiornamento dei campi di intestazione memorizzati)

In vari casi, una cache deve aggiornare i campi di intestazione di una risposta memorizzata da un'altra risposta (tipicamente più recente); ad esempio, vedere le sezioni 3.4, 4.3.4 e 4.3.5.

Nel farlo, una cache deve (MUST) aggiungere ciascun campo di intestazione dalla risposta fornita alla risposta memorizzata, sostituendo eventuali valori di campo esistenti, con le seguenti eccezioni:

• Campi di intestazione esclusi dalla memorizzazione secondo la sezione 3.1,

• Campi di intestazione da cui dipende la risposta memorizzata della cache, come descritto di seguito,

• Campi di intestazione che sono automaticamente elaborati e rimossi dal destinatario, come descritto di seguito, e

• Il campo di intestazione Content-Length.

In alcuni casi, le cache (specialmente negli user agent) memorizzano il risultato dell'elaborazione delle risposte ricevute anziché le risposte stesse, e l'aggiornamento dei campi di intestazione che influenzano tale elaborazione potrebbe causare comportamenti incoerenti e problemi di sicurezza. In tali casi, le cache possono (MAY) omettere questi campi di intestazione dall'aggiornamento delle risposte memorizzate nelle eccezioni, ma dovrebbero (SHOULD) limitare tali omissioni ai campi necessari per garantire l'integrità della risposta memorizzata.

Ad esempio, un browser potrebbe decodificare la codifica del contenuto di una risposta (Content Coding) quando viene ricevuta, creando una disconnessione tra i suoi dati memorizzati e i metadati originali della risposta. L'aggiornamento di quei metadati memorizzati con un campo di intestazione Content-Encoding diverso sarebbe problematico. Allo stesso modo, un browser potrebbe memorizzare un albero HTML analizzato anziché il contenuto ricevuto nella risposta; l'aggiornamento del campo di intestazione Content-Type in questa situazione non sarebbe fattibile, poiché eventuali presupposti fatti sul formato durante l'analisi sono ora incorporati.

Inoltre, alcuni campi sono automaticamente elaborati e rimossi dalle implementazioni HTTP, come il campo di intestazione Content-Range. Anche se non si verifica effettivamente alcuna elaborazione, le implementazioni possono (MAY) omettere automaticamente questi campi di intestazione dagli aggiornamenti.

Si noti che il prefisso Content-* non indica che un campo di intestazione è omesso dagli aggiornamenti; è una convenzione per i campi di intestazione MIME, non HTTP.

3.3 Storing Incomplete Responses (Memorizzazione di risposte incomplete)

Una cache può (MAY) memorizzare una risposta incompleta (vedere la sezione 6.1 di [HTTP]) se il metodo di richiesta è GET, il codice di stato della risposta è 200 (OK) e l'intera sezione di intestazione della risposta è stata ricevuta, a condizione che la risposta memorizzata sia registrata come incompleta. Allo stesso modo, una risposta 206 (Partial Content) può (MAY) essere memorizzata come una risposta 200 (OK) incompleta. Tuttavia, una cache non deve (MUST NOT) memorizzare risposte di contenuto incomplete o parziali se la cache non supporta i campi di intestazione Range e Content-Range o non comprende le unità di intervallo (Range Units) utilizzate in tali campi.

Una cache può (MAY) completare una risposta incompleta memorizzata effettuando richieste di intervallo successive (vedere la sezione 14.2 di [HTTP]) e combinando le risposte riuscite con la risposta memorizzata come definito nella sezione 3.4. Una cache non deve (MUST NOT) utilizzare una risposta incompleta per rispondere a una richiesta a meno che la risposta non sia stata completata o la richiesta sia parziale e specifichi un intervallo che si trova interamente all'interno della risposta incompleta. Una cache non deve (MUST NOT) inviare una risposta parziale a un client a meno che non sia esplicitamente contrassegnata utilizzando il codice di stato 206 (Partial Content).

3.4 Combining Partial Content (Combinazione di contenuto parziale)

Una risposta potrebbe trasferire solo una rappresentazione parziale se la connessione si chiude prematuramente o se la richiesta utilizza uno o più specificatori Range (vedere la sezione 14.2 di [HTTP]). Dopo diversi di questi trasferimenti, una cache potrebbe aver ricevuto diversi intervalli della stessa rappresentazione. Una cache può (MAY) combinare questi intervalli in una singola risposta memorizzata se condividono tutti lo stesso validatore forte (Strong Validator) e la cache è conforme ai requisiti del client nella sezione 15.3.7.3 di [HTTP], e riutilizzare quella risposta per soddisfare le richieste successive.

Quando si combina una nuova risposta con una o più risposte memorizzate, una cache deve (MUST) aggiornare i campi di intestazione della risposta memorizzata utilizzando i campi di intestazione forniti nella nuova risposta, secondo la sezione 3.2.

3.5 Storing Responses to Authenticated Requests (Memorizzazione delle risposte alle richieste autenticate)

Una cache condivisa non deve (MUST NOT) utilizzare una risposta memorizzata nella cache a una richiesta con un campo di intestazione Authorization (vedere la sezione 11.6.2 di [HTTP]) per soddisfare qualsiasi richiesta successiva a meno che la risposta non contenga un campo Cache-Control con una direttiva di risposta (sezione 5.2.2) che consente di essere memorizzata da una cache condivisa e la cache è conforme ai requisiti di quella direttiva per quella risposta.

In questa specifica, le seguenti direttive di risposta hanno questo effetto: must-revalidate (sezione 5.2.2.2), public (sezione 5.2.2.9) e s-maxage (sezione 5.2.2.10).