Passa al contenuto principale

4. Costruzione delle risposte dalle cache

Quando gli viene presentata una richiesta, una cache MUST NOT riutilizzare una risposta archiviata, a meno che:

  • l'effective request URI presentata (sezione 5.5 di [RFC7230]) e quella della risposta archiviata coincidano, e

  • il metodo della richiesta associato alla risposta archiviata ne consenta l'uso per la richiesta presentata, e

  • i campi di intestazione di selezione nominati dalla risposta archiviata (se presenti) corrispondano a quelli presentati (vedere la sezione 4.1), e

  • la richiesta presentata non contenga il pragma no-cache (sezione 5.4) né la direttiva di cache no-cache (sezione 5.2.1), a meno che la risposta archiviata sia stata validata con successo (sezione 4.3), e

  • la risposta archiviata non contenga la direttiva di cache no-cache (sezione 5.2.2.2), a meno che sia stata validata con successo (sezione 4.3), e

  • la risposta archiviata sia:

    • fresca (vedere la sezione 4.2), oppure

    • autorizzata a essere servita obsoleta (vedere la sezione 4.2.4), oppure

    • validata con successo (vedere la sezione 4.3).

Si noti che uno qualsiasi dei requisiti sopra elencati può essere sostituito da un'estensione di controllo della cache; vedere la sezione 5.2.3.

Quando una risposta archiviata viene usata per soddisfare una richiesta senza validazione, una cache MUST generare un campo di intestazione Age (sezione 5.1), sostituendo quello eventualmente presente nella risposta con un valore pari al current_age della risposta archiviata; vedere la sezione 4.2.3.

Una cache MUST inoltrare direttamente al server di origine («write through») le richieste con metodi non sicuri (sezione 4.2.1 di [RFC7231]); vale a dire, a una cache non è consentito generare una risposta a tale richiesta prima di aver inoltrato la richiesta e aver ricevuto una risposta corrispondente.

Si noti inoltre che le richieste non sicure possono invalidare risposte già archiviate; vedere la sezione 4.4.

Quando è archiviata più di una risposta adeguata, una cache MUST usare la risposta più recente (determinata dal campo di intestazione Date). Può anche inoltrare la richiesta con "Cache-Control: max-age=0" o "Cache-Control: no-cache" per eliminare l'ambiguità su quale risposta usare.

Una cache che non dispone di un orologio MUST NOT usare risposte archiviate senza rivalidarle a ogni utilizzo.

4.1. Calcolo delle chiavi secondarie con Vary​

Quando una cache riceve una richiesta che può essere soddisfatta da una risposta archiviata che ha un campo di intestazione Vary (sezione 7.1.4 di [RFC7231]), MUST NOT usare tale risposta a meno che tutti i campi di intestazione di selezione nominati dal campo di intestazione Vary non corrispondano sia nella richiesta originale (ossia quella associata alla risposta archiviata) sia nella richiesta presentata.

I campi di intestazione di selezione di due richieste corrispondono se e solo se quelli della prima richiesta possono essere trasformati in quelli della seconda applicando una qualsiasi delle seguenti operazioni:

  • aggiungere o rimuovere spazi bianchi, dove la sintassi del campo di intestazione lo consente,

  • combinare più campi di intestazione con lo stesso nome di campo (vedere la sezione 3.2 di [RFC7230]),

  • normalizzare entrambi i valori dei campi in un modo noto per avere semantica identica, in base alla specifica del campo di intestazione (ad esempio, riordinare i valori dei campi quando l'ordine non è significativo; normalizzare le maiuscole/minuscole, quando i valori sono definiti come non sensibili alle maiuscole/minuscole).

Se (dopo qualsiasi normalizzazione che possa aver luogo) un campo di intestazione è assente da una richiesta, può corrispondere a un'altra richiesta solo se è assente anche in essa.

Un valore del campo di intestazione Vary pari a "*" non corrisponde mai.

La risposta archiviata con i campi di intestazione di selezione corrispondenti è nota come risposta selezionata.

Se sono disponibili più risposte selezionate (potenzialmente incluse risposte senza campo di intestazione Vary), la cache dovrà sceglierne una da usare. Quando un campo di intestazione di selezione dispone di un meccanismo noto per farlo (ad esempio i qvalue su Accept e campi di intestazione di richiesta simili), tale meccanismo MAY essere usato per selezionare le risposte preferite; tra le restanti, si usa la risposta più recente (determinata dal campo di intestazione Date), come indicato nella sezione 4.

Se non è disponibile alcuna risposta selezionata, la cache non può soddisfare la richiesta presentata. Tipicamente, essa viene inoltrata al server di origine in una richiesta (possibilmente condizionale; vedere la sezione 4.3).

4.2. Freschezza​

Una risposta fresca è una la cui età non ha ancora superato la sua durata di freschezza. Al contrario, una risposta obsoleta è una in cui ciò è avvenuto.

La durata di freschezza di una risposta è l'intervallo di tempo tra la sua generazione da parte del server di origine e il suo tempo di scadenza. Un tempo di scadenza esplicito è il momento in cui il server di origine intende che una risposta archiviata non possa più essere usata da una cache senza ulteriore validazione, mentre un tempo di scadenza euristico viene assegnato da una cache quando non è disponibile alcun tempo di scadenza esplicito.

L'età di una risposta è il tempo trascorso da quando è stata generata o validata con successo presso il server di origine.

Quando una risposta è "fresca" nella cache, può essere usata per soddisfare richieste successive senza contattare il server di origine, migliorando così l'efficienza.

Il meccanismo principale per determinare la freschezza consiste, per un server di origine, nel fornire un tempo di scadenza esplicito nel futuro, usando il campo di intestazione Expires (sezione 5.3) o la direttiva di risposta max-age (sezione 5.2.2.8). In genere, i server di origine assegnano alle risposte tempi di scadenza espliciti futuri nella convinzione che la rappresentazione non cambierà probabilmente in modo semanticamente significativo prima che il tempo di scadenza sia raggiunto.

Se un server di origine desidera forzare una cache a validare ogni richiesta, può assegnare un tempo di scadenza esplicito nel passato per indicare che la risposta è già obsoleta. Le cache conformi normalmente validano una risposta in cache obsoleta prima di riutilizzarla per richieste successive (vedere la sezione 4.2.4).

Poiché i server di origine non forniscono sempre tempi di scadenza espliciti, alle cache è anche consentito usare un'euristica per determinare un tempo di scadenza in determinate circostanze (vedere la sezione 4.2.2).

Il calcolo per determinare se una risposta è fresca è:

response_is_fresh = (freshness_lifetime > current_age)

freshness_lifetime è definito nella sezione 4.2.1; current_age è definito nella sezione 4.2.3.

I client possono inviare le direttive di cache max-age o min-fresh in una richiesta per restringere o allentare i calcoli di freschezza per la risposta corrispondente (sezione 5.2.1).

Nel calcolare la freschezza, per evitare problemi comuni nell'analisi delle date:

  • Sebbene tutti i formati di data siano specificati come sensibili alle maiuscole/minuscole, un destinatario della cache SHOULD confrontare i nomi dei giorni, delle settimane e dei fusi orari senza distinguere le maiuscole/minuscole.

  • Se l'implementazione interna del tempo di un destinatario della cache ha una risoluzione inferiore al valore di un HTTP-date, il destinatario MUST rappresentare internamente una data Expires analizzata come il tempo più vicino uguale o precedente al valore ricevuto.

  • Un destinatario della cache MUST NOT consentire ai fusi orari locali di influenzare il calcolo o il confronto di un'età o di un tempo di scadenza.

  • Un destinatario della cache SHOULD considerare non valida, per il calcolo della scadenza, una data con un'abbreviazione di fuso orario diversa da GMT o UTC.

Si noti che la freschezza si applica solo al funzionamento della cache; non può essere usata per forzare uno user agent ad aggiornare la propria visualizzazione o a ricaricare una risorsa. Per una spiegazione della differenza tra cache e meccanismi di cronologia, vedere la sezione 6.

4.2.1. Calcolo della durata di freschezza​

Una cache può calcolare la durata di freschezza (indicata come freshness_lifetime) di una risposta usando la prima corrispondenza tra le seguenti:

  • se la cache è condivisa e la direttiva di risposta s-maxage (sezione 5.2.2.9) è presente, usarne il valore, oppure

  • se la direttiva di risposta max-age (sezione 5.2.2.8) è presente, usarne il valore, oppure

  • se il campo di intestazione di risposta Expires (sezione 5.3) è presente, usarne il valore meno il valore del campo di intestazione di risposta Date, oppure

  • altrimenti, nella risposta non è presente alcun tempo di scadenza esplicito. Potrebbe essere applicabile una durata di freschezza euristica; vedere la sezione 4.2.2.

Si noti che questo calcolo non è vulnerabile allo sfasamento dell'orologio, poiché tutte le informazioni provengono dal server di origine.

Quando per una data direttiva è presente più di un valore (ad esempio due campi di intestazione Expires, più direttive Cache-Control: max-age), il valore della direttiva è considerato non valido. Le cache sono incoraggiate a considerare obsolete le risposte con informazioni di freschezza non valide.

4.2.2. Calcolo della freschezza euristica​

Poiché i server di origine non forniscono sempre tempi di scadenza espliciti, una cache MAY assegnare un tempo di scadenza euristico quando non è specificato un tempo esplicito, impiegando algoritmi che usano altri valori di campi di intestazione (come il tempo Last-Modified) per stimare un tempo di scadenza plausibile. Questa specifica non fornisce algoritmi specifici, ma impone vincoli di caso peggiore ai loro risultati.

Una cache MUST NOT usare euristiche per determinare la freschezza quando nella risposta archiviata è presente un tempo di scadenza esplicito. A causa dei requisiti della sezione 3, ciò significa che, di fatto, le euristiche possono essere usate solo su risposte prive di freschezza esplicita i cui codici di stato sono definiti come memorizzabili in cache per impostazione predefinita (vedere la sezione 6.1 di [RFC7231]), e su quelle risposte prive di freschezza esplicita che sono state contrassegnate come esplicitamente memorizzabili in cache (ad esempio con una direttiva di risposta "public").

Se la risposta ha un campo di intestazione Last-Modified (sezione 2.2 di [RFC7232]), le cache sono incoraggiate a usare un valore di scadenza euristico non superiore a una frazione dell'intervallo trascorso da quel momento. Un'impostazione tipica di questa frazione potrebbe essere il 10%.

Quando un'euristica viene usata per calcolare la durata di freschezza, una cache SHOULD generare nella risposta un campo di intestazione Warning con warn-code 113 (vedere la sezione 5.5.4) se il suo current_age supera le 24 ore e tale avviso non è già presente.

Nota: La sezione 13.9 di [RFC2616] vietava alle cache di calcolare la freschezza euristica per URI con componenti di query (ossia quelli contenenti '?'). In pratica, ciò non è stato ampiamente implementato. Pertanto, i server di origine sono incoraggiati a inviare direttive esplicite (ad esempio Cache-Control: no-cache) se desiderano precludere la memorizzazione in cache.

4.2.3. Calcolo dell'età​

Il campo di intestazione Age è usato per comunicare un'età stimata del messaggio di risposta quando esso è ottenuto da una cache. Il valore del campo Age è la stima della cache del numero di secondi trascorsi da quando la risposta è stata generata o validata dal server di origine. In sostanza, il valore Age è la somma del tempo in cui la risposta ha risieduto in ciascuna delle cache lungo il percorso dal server di origine, più la quantità di tempo in cui è stata in transito lungo i percorsi di rete.

Per il calcolo dell'età si usano i seguenti dati:

age_value

Il termine "age_value" indica il valore del campo di intestazione Age (sezione 5.1), in una forma adatta a un'operazione aritmetica; oppure 0, se non disponibile.

date_value

Il termine "date_value" indica il valore del campo di intestazione Date, in una forma adatta alle operazioni aritmetiche. Per la definizione del campo di intestazione Date e per i requisiti riguardanti le risposte che ne sono prive, vedere la sezione 7.1.1.2 di [RFC7231].

now

Il termine "now" significa "il valore corrente dell'orologio dell'host che esegue il calcolo". Un host dovrebbe usare NTP ([RFC5905]) o un protocollo simile per sincronizzare i propri orologi con il tempo universale coordinato.

request_time

Il valore corrente dell'orologio dell'host al momento in cui è stata effettuata la richiesta che ha prodotto la risposta archiviata.

response_time

Il valore corrente dell'orologio dell'host al momento in cui è stata ricevuta la risposta.

L'età di una risposta può essere calcolata in due modi del tutto indipendenti:

  1. l'"apparent_age": response_time meno date_value, se l'orologio locale è ragionevolmente ben sincronizzato con quello del server di origine. Se il risultato è negativo, viene sostituito da zero.

  2. il "corrected_age_value", se tutte le cache lungo il percorso della risposta implementano HTTP/1.1. Una cache MUST interpretare questo valore rispetto al momento in cui la richiesta è stata avviata, non al momento in cui la risposta è stata ricevuta.

apparent_age = max(0, response_time - date_value);

response_delay = response_time - request_time;
corrected_age_value = age_value + response_delay;

Questi vengono combinati come:

corrected_initial_age = max(apparent_age, corrected_age_value);

a meno che la cache non abbia fiducia nel valore del campo di intestazione Age (ad esempio, perché non ci sono hop HTTP/1.0 nel campo di intestazione Via); in tal caso il corrected_age_value MAY essere usato come corrected_initial_age.

Il current_age di una risposta archiviata può quindi essere calcolato sommando al corrected_initial_age la quantità di tempo (in secondi) trascorsa da quando la risposta archiviata è stata validata l'ultima volta dal server di origine.

resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;

4.2.4. Fornitura di risposte obsolete​

Una risposta "obsoleta" è una che ha informazioni di scadenza esplicite oppure a cui è consentito calcolare una scadenza euristica, ma non è fresca secondo i calcoli della sezione 4.2.

Una cache MUST NOT generare una risposta obsoleta se ciò è vietato da una direttiva esplicita nel protocollo (ad esempio da una direttiva di cache "no-store" o "no-cache", da una direttiva di risposta di cache "must-revalidate", o da un'applicabile direttiva di risposta di cache "s-maxage" o "proxy-revalidate"; vedere la sezione 5.2.2).

Una cache MUST NOT inviare risposte obsolete a meno che non sia disconnessa (ossia non possa contattare il server di origine o trovare in altro modo un percorso di inoltro) o che ciò sia esplicitamente consentito (ad esempio dalla direttiva di richiesta max-stale; vedere la sezione 5.2.1).

Una cache SHOULD generare un campo di intestazione Warning con il warn-code 110 nelle risposte obsolete (vedere la sezione 5.5.1). Analogamente, una cache SHOULD generare un warn-code 112 nelle risposte obsolete se la cache è disconnessa (vedere la sezione 5.5.3).

Una cache SHOULD NOT generare un nuovo campo di intestazione Warning quando inoltra una risposta che non ha un campo di intestazione Age, anche se la risposta è già obsoleta. Una cache non deve validare una risposta che è semplicemente diventata obsoleta in transito.

4.3. Validazione​

Quando una cache ha una o più risposte archiviate per un URI richiesto, ma non può servirne nessuna (ad esempio perché non sono fresche, o perché non se ne può selezionare una; vedere la sezione 4.1), può usare il meccanismo delle richieste condizionali [RFC7232] nella richiesta inoltrata per dare al successivo server in ingresso l'opportunità di selezionare una risposta archiviata valida da usare, aggiornando nel frattempo i metadati archiviati, oppure di sostituire la o le risposte archiviate con una nuova risposta. Questo processo è noto come "validazione" o "rivalidazione" della risposta archiviata.

4.3.1. Invio di una richiesta di validazione​

Quando invia una richiesta condizionale per la validazione della cache, una cache invia uno o più campi di intestazione di precondizione contenenti i metadati del validatore tratti dalla o dalle proprie risposte archiviate; i destinatari li confrontano poi per determinare se una risposta archiviata è equivalente a una rappresentazione corrente della risorsa.

Uno di tali validatori è il timestamp fornito in un campo di intestazione Last-Modified (sezione 2.2 di [RFC7232]), che può essere usato in un campo di intestazione If-Modified-Since per la validazione della risposta, oppure in un campo di intestazione If-Unmodified-Since o If-Range per la selezione della rappresentazione (ossia il client si riferisce specificamente a una rappresentazione ottenuta in precedenza con quel timestamp).

Un altro validatore è l'entity-tag fornito in un campo di intestazione ETag (sezione 2.3 di [RFC7232]). Uno o più entity-tag, che indicano una o più risposte archiviate, possono essere usati in un campo di intestazione If-None-Match per la validazione della risposta, oppure in un campo di intestazione If-Match o If-Range per la selezione della rappresentazione (ossia il client si riferisce specificamente a una o più rappresentazioni ottenute in precedenza con gli entity-tag elencati).

4.3.2. Gestione di una richiesta di validazione ricevuta​

Ogni client nella catena di richieste può avere la propria cache, quindi è comune che una cache presso un intermediario riceva richieste condizionali da altre cache (in uscita). Analogamente, alcuni user agent usano richieste condizionali per limitare i trasferimenti di dati alle rappresentazioni modificate di recente o per completare il trasferimento di una rappresentazione parzialmente recuperata.

Se una cache riceve una richiesta che può essere soddisfatta riutilizzando una delle sue risposte archiviate 200 (OK) o 206 (Partial Content), la cache SHOULD valutare le eventuali precondizioni applicabili dei campi di intestazione condizionali ricevute in tale richiesta rispetto ai validatori corrispondenti contenuti nella risposta selezionata. Una cache MUST NOT valutare i campi di intestazione condizionali che si applicano solo a un server di origine, che si trovano in una richiesta con semantica che non può essere soddisfatta con una risposta in cache, o che sono applicati a una risorsa di destinazione per la quale non ha risposte archiviate; tali precondizioni sono probabilmente destinate a qualche altro server (in ingresso).

La corretta valutazione delle richieste condizionali da parte di una cache dipende dai campi di intestazione di precondizione ricevuti e dalla loro precedenza, come definito nella sezione 6 di [RFC7232]. I campi di intestazione condizionali If-Match e If-Unmodified-Since non sono applicabili a una cache.

Una richiesta contenente un campo di intestazione If-None-Match (sezione 3.2 di [RFC7232]) indica che il client desidera validare una o più delle proprie risposte archiviate rispetto alla risposta archiviata che viene selezionata dalla cache. Se il valore del campo è "*", o se il valore del campo è un elenco di entity-tag e almeno uno di essi corrisponde all'entity-tag della risposta archiviata selezionata, un destinatario della cache SHOULD generare una risposta 304 (Not Modified) (usando i metadati della risposta archiviata selezionata) invece di inviare quella risposta archiviata.

Quando una cache decide di rivalidare le proprie risposte archiviate per una richiesta che contiene un elenco If-None-Match di entity-tag, la cache MAY combinare l'elenco ricevuto con un elenco di entity-tag tratto dal proprio insieme di risposte archiviate (fresche o obsolete) e inviare l'unione dei due elenchi come valore sostitutivo del campo di intestazione If-None-Match nella richiesta inoltrata. Se una risposta archiviata contiene solo contenuto parziale, la cache MUST NOT includere il suo entity-tag nell'unione, a meno che la richiesta non riguardi un intervallo che sarebbe interamente soddisfatto da quella risposta archiviata parziale. Se la risposta alla richiesta inoltrata è 304 (Not Modified) e ha un valore del campo di intestazione ETag con un entity-tag che non è nell'elenco del client, la cache MUST generare una risposta 200 (OK) per il client riutilizzando la corrispondente risposta archiviata, come aggiornata dai metadati della risposta 304 (sezione 4.3.4).

Se non è presente alcun campo di intestazione If-None-Match, una richiesta contenente un campo di intestazione If-Modified-Since (sezione 3.3 di [RFC7232]) indica che il client desidera validare una o più delle proprie risposte archiviate per data di modifica. Un destinatario della cache SHOULD generare una risposta 304 (Not Modified) (usando i metadati della risposta archiviata selezionata) se uno dei seguenti casi è vero: 1) la risposta archiviata selezionata ha un valore del campo Last-Modified precedente o uguale al timestamp condizionale; 2) nessun campo Last-Modified è presente nella risposta archiviata selezionata, ma essa ha un valore del campo Date precedente o uguale al timestamp condizionale; oppure 3) né Last-Modified né Date sono presenti nella risposta archiviata selezionata, ma la cache ha registrato che è stata ricevuta in un momento precedente o uguale al timestamp condizionale.

Una cache che implementa risposte parziali alle richieste di intervallo, come definito in [RFC7233], deve anche valutare un campo di intestazione If-Range ricevuto (sezione 3.2 di [RFC7233]) rispetto alla sua risposta archiviata selezionata.

4.3.3. Gestione di una risposta di validazione​

La gestione da parte della cache di una risposta a una richiesta condizionale dipende dal suo codice di stato:

  • Un codice di stato di risposta 304 (Not Modified) indica che la risposta archiviata può essere aggiornata e riutilizzata; vedere la sezione 4.3.4.

  • Una risposta completa (ossia con un corpo di payload) indica che nessuna delle risposte archiviate nominate nella richiesta condizionale è adeguata. Al contrario, la cache MUST usare la risposta completa per soddisfare la richiesta e MAY sostituire la o le risposte archiviate.

  • Tuttavia, se una cache riceve una risposta 5xx (Server Error) mentre tenta di validare una risposta, può inoltrare questa risposta al client richiedente oppure comportarsi come se il server non avesse risposto. In quest'ultimo caso, la cache MAY inviare una risposta archiviata in precedenza (vedere la sezione 4.2.4).

4.3.4. Aggiornamento delle risposte archiviate in seguito a validazione​

Quando una cache riceve una risposta 304 (Not Modified) e ha già una o più risposte archiviate 200 (OK) per la stessa chiave di cache, la cache deve identificare quali delle risposte archiviate sono aggiornate da questa nuova risposta, e poi aggiornare la o le risposte archiviate con le nuove informazioni fornite nella risposta 304.

La risposta archiviata da aggiornare viene identificata usando la prima corrispondenza (se presente) tra le seguenti:

  • Se la nuova risposta contiene un validatore forte (vedere la sezione 2.1 di [RFC7232]), tale validatore forte identifica la rappresentazione selezionata da aggiornare. Tutte le risposte archiviate con lo stesso validatore forte vengono selezionate. Se nessuna delle risposte archiviate contiene lo stesso validatore forte, la cache MUST NOT usare la nuova risposta per aggiornare alcuna risposta archiviata.

  • Se la nuova risposta contiene un validatore debole e tale validatore corrisponde a una delle risposte archiviate della cache, viene selezionata per l'aggiornamento la più recente di quelle risposte archiviate corrispondenti.

  • Se la nuova risposta non include alcuna forma di validatore (come nel caso in cui un client generi una richiesta If-Modified-Since da una fonte diversa dal campo di intestazione di risposta Last-Modified), e c'è una sola risposta archiviata, e anche quella risposta archiviata è priva di validatore, allora quella risposta archiviata viene selezionata per l'aggiornamento.

Se una risposta archiviata viene selezionata per l'aggiornamento, la cache MUST:

  • eliminare tutti i campi di intestazione Warning nella risposta archiviata con warn-code 1xx (vedere la sezione 5.5);

  • conservare tutti i campi di intestazione Warning nella risposta archiviata con warn-code 2xx; e

  • usare gli altri campi di intestazione forniti nella risposta 304 (Not Modified) per sostituire tutte le istanze dei campi di intestazione corrispondenti nella risposta archiviata.

4.3.5. Aggiornamento delle risposte tramite HEAD​

Una risposta al metodo HEAD è identica a quella che sarebbe stata una richiesta equivalente effettuata con GET, tranne per il fatto che è priva di corpo. Questa proprietà delle risposte HEAD può essere usata per invalidare o aggiornare una risposta GET in cache se il meccanismo più efficiente della richiesta GET condizionale non è disponibile (a causa dell'assenza di validatori nella risposta archiviata) o se la trasmissione del corpo della rappresentazione non è desiderata anche se è cambiato.

Quando una cache effettua una richiesta HEAD in ingresso per un dato target di richiesta e riceve una risposta 200 (OK), la cache SHOULD aggiornare o invalidare ciascuna delle sue risposte GET archiviate che avrebbero potuto essere selezionate per quella richiesta (vedere la sezione 4.1).

Per ciascuna delle risposte archiviate che avrebbero potuto essere selezionate, se la risposta archiviata e la risposta HEAD hanno valori corrispondenti per qualsiasi campo di validatore ricevuto (ETag e Last-Modified) e, se la risposta HEAD ha un campo di intestazione Content-Length, il valore di Content-Length corrisponde a quello della risposta archiviata, la cache SHOULD aggiornare la risposta archiviata come descritto di seguito; altrimenti, la cache SHOULD considerare la risposta archiviata obsoleta.

Se una cache aggiorna una risposta archiviata con i metadati forniti in una risposta HEAD, la cache MUST:

  • eliminare tutti i campi di intestazione Warning nella risposta archiviata con warn-code 1xx (vedere la sezione 5.5);

  • conservare tutti i campi di intestazione Warning nella risposta archiviata con warn-code 2xx; e

  • usare gli altri campi di intestazione forniti nella risposta HEAD per sostituire tutte le istanze dei campi di intestazione corrispondenti nella risposta archiviata e aggiungere i nuovi campi di intestazione alla sezione di intestazione della risposta archiviata, salvo diversa restrizione del campo di intestazione Cache-Control.

4.4. Invalidazione​

Poiché i metodi di richiesta non sicuri (sezione 4.2.1 di [RFC7231]) come PUT, POST o DELETE hanno il potenziale di modificare lo stato sul server di origine, le cache intermedie possono usarli per mantenere aggiornati i propri contenuti.

Una cache MUST invalidare l'effective Request URI (sezione 5.5 di [RFC7230]) nonché l'URI o gli URI nei campi di intestazione di risposta Location e Content-Location (se presenti) quando viene ricevuto un codice di stato non di errore in risposta a un metodo di richiesta non sicuro.

Tuttavia, una cache MUST NOT invalidare un URI proveniente da un campo di intestazione di risposta Location o Content-Location se la parte host di tale URI differisce dalla parte host nell'effective request URI (sezione 5.5 di [RFC7230]). Ciò aiuta a prevenire attacchi di negazione del servizio.

Una cache MUST invalidare l'effective request URI (sezione 5.5 di [RFC7230]) quando riceve una risposta non di errore a una richiesta con un metodo la cui sicurezza è sconosciuta.

Qui, una "risposta non di errore" è una con un codice di stato 2xx (Successful) o 3xx (Redirection). "Invalidare" significa che la cache rimuoverà tutte le risposte archiviate relative all'effective request URI oppure le contrassegnerà come "non valide" e bisognose di una validazione obbligatoria prima che possano essere inviate in risposta a una richiesta successiva.

Si noti che ciò non garantisce che tutte le risposte appropriate siano invalidate. Ad esempio, una richiesta che modifica lo stato potrebbe invalidare risposte nelle cache che attraversa, ma le risposte pertinenti potrebbero essere ancora archiviate in altre cache che non ha attraversato.