4. Constructing Responses from Caches (Costruzione di risposte dalle cache)

Quando viene presentata una richiesta, una cache non deve (MUST NOT) riutilizzare una risposta memorizzata a meno che non siano soddisfatte tutte le seguenti condizioni:

• L'URI di destinazione presentato (vedere la sezione 7.1 di [HTTP]) corrisponde all'URI di destinazione della risposta memorizzata, e

• Il metodo di richiesta associato alla risposta memorizzata ne consente l'utilizzo per la richiesta presentata, e

• I campi di intestazione della richiesta specificati dalla risposta memorizzata (se presenti) corrispondono a quelli della richiesta presentata (vedere la sezione 4.1), e

• La risposta memorizzata non contiene una direttiva no-cache (sezione 5.2.2.4), a meno che non sia stata validata con successo (sezione 4.3), e

• La risposta memorizzata è una delle seguenti:

  • Fresca (vedere la sezione 4.2), o

  • Autorizzata a essere servita obsoleta (vedere la sezione 4.2.4), o

  • Validata con successo (vedere la sezione 4.3).

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

Quando si utilizza una risposta memorizzata per soddisfare una richiesta senza validazione, una cache deve (MUST) generare un campo di intestazione Age (sezione 5.1), sostituendo qualsiasi campo Age presente nella risposta con un valore uguale al current_age della risposta memorizzata; vedere la sezione 4.2.3.

Una cache deve (MUST) inoltrare direttamente le richieste con metodi non sicuri (vedere la sezione 9.2.1 di [HTTP]) al server di origine; cioè, una cache non è autorizzata a generare una risposta a tale richiesta prima di aver inoltrato la richiesta e ricevuto una risposta corrispondente.

Inoltre, si noti che le richieste non sicure potrebbero invalidare le risposte memorizzate; vedere la sezione 4.4.

Una cache può (MAY) utilizzare una risposta memorizzata o memorizzabile per soddisfare più richieste, a condizione che la risposta sia autorizzata a essere riutilizzata per le richieste in questione. Ciò consente alle cache di "collassare le richieste (Collapse Requests)" -- o combinare più richieste in ingresso in una singola richiesta di inoltro durante un cache miss -- riducendo così il carico sul server di origine e sulla rete. Tuttavia, si noti che se la cache non può utilizzare la risposta restituita per alcune o tutte le richieste collassate, dovrà inoltrare tali richieste per soddisfarle, il che può introdurre latenza aggiuntiva.

Quando sono memorizzate più risposte appropriate, una cache deve (MUST) utilizzare la risposta più recente (come determinato dal campo di intestazione Date). Può anche inoltrare la richiesta con "Cache-Control: max-age=0" o "Cache-Control: no-cache" per disambiguare quale risposta utilizzare.

Una cache senza orologio (vedere la sezione 5.6.7 di [HTTP]) deve (MUST) rivalidare le risposte memorizzate ad ogni utilizzo.

4.1 Calculating Cache Keys with the Vary Header Field (Calcolo delle chiavi di cache con il campo di intestazione Vary)

Quando una cache riceve una richiesta che può essere soddisfatta da una risposta memorizzata e quella risposta memorizzata contiene un campo di intestazione Vary (vedere la sezione 12.5.5 di [HTTP]), la cache non deve (MUST NOT) utilizzare quella risposta memorizzata senza rivalidazione a meno che tutti i campi di intestazione della richiesta nominati dal valore del campo Vary corrispondano sia nella richiesta originale (cioè, la richiesta che ha causato la memorizzazione della risposta in cache) che nella richiesta presentata.

I campi di intestazione di due richieste sono definiti come corrispondenti se e solo se i campi di intestazione della prima richiesta possono essere trasformati nei campi di intestazione della seconda richiesta applicando una qualsiasi delle seguenti operazioni:

• Aggiunta o rimozione di spazi bianchi, dove consentito dalla sintassi del campo di intestazione

• Combinazione di più righe di campo di intestazione con lo stesso nome di campo (vedere la sezione 5.2 di [HTTP])

• Normalizzazione di entrambi i valori dei campi di intestazione in modo noto per avere semantica identica, secondo la specifica del campo di intestazione (ad esempio, riordino dei valori dei campi quando l'ordine non è significativo; normalizzazione delle maiuscole/minuscole, dove i valori sono definiti come insensibili alle maiuscole)

Se un campo di intestazione è assente da una richiesta, può corrispondere solo se è anche assente dall'altra richiesta.

Una risposta memorizzata con un valore del campo di intestazione Vary contenente il membro "*" fallisce sempre la corrispondenza.

Se più risposte memorizzate corrispondono, una cache dovrà sceglierne una da utilizzare. Quando i campi di intestazione della richiesta nominati hanno un meccanismo di ordinamento delle preferenze noto (ad esempio, qvalues su Accept e campi di intestazione della richiesta simili), quel meccanismo può (MAY) essere utilizzato per selezionare la risposta preferita. Se non esiste tale meccanismo o si ottengono risposte ugualmente preferite, viene selezionata la risposta più recente (come determinato dal campo di intestazione Date), come da sezione 4.

Alcune risorse omettono erroneamente il campo di intestazione Vary dalla loro risposta predefinita (cioè, quella inviata quando la richiesta non esprime alcuna preferenza), con l'effetto che viene selezionata per le richieste successive a quella risorsa anche quando è disponibile una risposta più preferita. Quando una cache ha più risposte memorizzate per un URI di destinazione e una o più omettono il campo di intestazione Vary, la cache dovrebbe (SHOULD) selezionare la risposta memorizzata più recente (vedere la sezione 4.2.3) che ha un valore del campo Vary valido.

Se nessuna risposta memorizzata corrisponde, la cache non può soddisfare la richiesta presentata. Tipicamente, la richiesta viene inoltrata al server di origine, possibilmente con precondizioni aggiunte per descrivere le risposte che la cache ha già memorizzato (sezione 4.3).

4.2 Freshness (Freschezza)

Una risposta "fresca (Fresh)" è quella la cui età non ha ancora superato la sua durata di vita di freschezza. Al contrario, una risposta "obsoleta (Stale)" è quella in cui è stata superata.

La "durata di vita di freschezza (Freshness Lifetime)" di una risposta è il periodo di tempo tra la sua generazione da parte del server di origine e il suo tempo di scadenza. Un "tempo di scadenza esplicito (Explicit Expiration Time)" è il momento in cui il server di origine intende che una cache non utilizzi più una risposta memorizzata senza ulteriore validazione, mentre un "tempo di scadenza euristico (Heuristic Expiration Time)" è uno assegnato da una cache quando non è disponibile un tempo di scadenza esplicito.

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

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

Il meccanismo principale per determinare la freschezza è che il server di origine fornisca un tempo di scadenza esplicito nel futuro, utilizzando il campo di intestazione Expires (sezione 5.3) o la direttiva di risposta max-age (sezione 5.2.2.1). Generalmente, un server di origine assegnerà un tempo di scadenza esplicito futuro a una risposta, credendo che la rappresentazione non sia probabile che cambi in modo semanticamente significativo prima di quel tempo di scadenza.

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 valideranno una risposta in cache obsoleta prima di riutilizzarla (vedere la sezione 4.2.4).

Poiché i server di origine non forniscono sempre tempi di scadenza espliciti, alle cache è anche consentito utilizzare un'euristica per determinare un tempo di scadenza in alcune 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 richiesta max-age o min-fresh (sezione 5.2.1) per suggerire limiti sui calcoli di freschezza per la risposta corrispondente. Tuttavia, le cache non sono tenute a onorarli.

Quando si calcola la freschezza, per evitare problemi comuni nell'analisi delle date:

• Sebbene tutti i formati di data siano specificati come sensibili alle maiuscole, i destinatari della cache dovrebbero (SHOULD) abbinare i valori dei campi senza distinzione tra maiuscole e minuscole.

• Se la rappresentazione interna del tempo di un destinatario della cache ha una risoluzione inferiore al valore di HTTP-date, il destinatario deve (MUST) rappresentare internamente la data Expires analizzata come il primo momento uguale o precedente al valore ricevuto.

• Un destinatario della cache non deve (MUST NOT) consentire al fuso orario locale di influenzare il calcolo o il confronto dell'età o dei tempi di scadenza.

• Un destinatario della cache dovrebbe (SHOULD) considerare le date con abbreviazioni di fuso orario diverse da "GMT" come non valide per il calcolo della scadenza.

Si noti che la freschezza si applica solo alle operazioni della cache; non può essere utilizzata per forzare un user agent ad aggiornare la sua visualizzazione o ricaricare una risorsa. Vedere la sezione 6 per una spiegazione delle differenze tra cache e meccanismi di cronologia.

4.2.1 Calculating Freshness Lifetime (Calcolo della durata di vita di freschezza)

Una cache può calcolare la durata di vita di freschezza (denotata come freshness_lifetime) di una risposta valutando le seguenti regole e utilizzando la prima corrispondenza:

• Se la cache è condivisa e la direttiva di risposta s-maxage (sezione 5.2.2.10) è presente, utilizzare il suo valore, o

• Se la direttiva di risposta max-age (sezione 5.2.2.1) è presente, utilizzare il suo valore, o

• Se il campo di intestazione di risposta Expires (sezione 5.3) è presente, utilizzare il suo valore meno il valore del campo di intestazione di risposta Date (utilizzando il momento in cui il messaggio è stato ricevuto se non presente, come da sezione 6.6.1 di [HTTP]), o

• Altrimenti, nessun tempo di scadenza esplicito è presente nella risposta. Una durata di vita di freschezza euristica potrebbe essere applicabile; vedere la sezione 4.2.2.

Si noti che questo calcolo è inteso a ridurre lo sfasamento dell'orologio utilizzando il più possibile le informazioni dall'orologio del server di origine.

Quando ci sono più occorrenze di una data direttiva (ad esempio, due righe di campo di intestazione Expires o più direttive Cache-Control: max-age), dovrebbe essere utilizzata la prima occorrenza o la risposta dovrebbe essere considerata obsoleta. Se le direttive sono in conflitto (ad esempio, sono presenti sia max-age che no-cache), dovrebbe essere onorata la direttiva più restrittiva. Le cache sono incoraggiate a considerare le risposte con informazioni di freschezza non valide (ad esempio, una direttiva max-age con contenuto non intero) come obsolete.

4.2.2 Calculating Heuristic Freshness (Calcolo della freschezza euristica)

Poiché i server di origine non forniscono sempre tempi di scadenza espliciti, una cache può (MAY) assegnare un tempo di scadenza euristico quando non viene specificato alcun tempo esplicito, utilizzando un algoritmo che impiega altri valori dei campi di intestazione (come il tempo Last-Modified) per stimare un tempo di scadenza plausibile. Questa specifica non fornisce un algoritmo specifico ma impone vincoli del caso peggiore sui suoi risultati.

Una cache non deve (MUST NOT) utilizzare euristiche per determinare la freschezza quando è presente un tempo di scadenza esplicito in una risposta memorizzata. Poiché il requisito della sezione 3 significa che le euristiche possono essere utilizzate solo su risposte senza freschezza esplicita che sono consentite dal loro codice di stato ad essere euristicamente memorizzabili (vedere, ad esempio, la sezione 15.1 di [HTTP]) o sono state contrassegnate come esplicitamente memorizzabili (ad esempio, con una direttiva di risposta public).

Si noti che nelle specifiche precedenti, i codici di stato delle risposte euristicamente memorizzabili erano noti come "memorizzabili per impostazione predefinita (Cacheable by Default)".

Se la risposta ha un campo di intestazione Last-Modified (vedere la sezione 8.8.2 di [HTTP]), le cache sono incoraggiate a utilizzare un valore di scadenza euristico che non superi una frazione dell'intervallo da quel momento. Un'impostazione tipica di questa frazione potrebbe essere del 10%.

Nota: Le versioni precedenti della specifica HTTP ([RFC2616], sezione 13.9) proibivano alle cache di calcolare la freschezza euristica per gli URI con componenti di query (cioè, 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 impedire la memorizzazione nella cache.

4.2.3 Calculating Age (Calcolo dell'età)

Il campo di intestazione Age viene utilizzato per trasmettere un'età stimata del messaggio di risposta quando ottenuto da una cache. Il valore del campo Age è la stima della cache del tempo in secondi trascorso da quando la risposta è stata generata o validata presso il server di origine. Pertanto, il valore Age è la somma del tempo in cui la risposta è risieduta in ciascuna cache lungo il percorso dal server di origine all'arrivo, più il tempo trascorso in transito lungo il percorso di rete.

I seguenti dati sono utilizzati per il calcolo dell'età:

age_value Il termine "age_value" denota il valore del campo di intestazione Age (sezione 5.1) in una forma appropriata per operazioni aritmetiche; o 0, se non disponibile.

date_value Il termine "date_value" denota il valore del campo di intestazione Date in una forma appropriata per operazioni aritmetiche. Vedere la sezione 6.6.1 di [HTTP] per la definizione del campo di intestazione Date e i requisiti per le risposte senza di esso.

now Il termine "now" denota il valore corrente dell'orologio di questa implementazione (vedere la sezione 5.6.7 di [HTTP]).

request_time Il valore dell'orologio al momento della richiesta che ha prodotto la risposta memorizzata.

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

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

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

2. Il "corrected_age_value", se tutte le cache lungo il percorso di risposta implementano HTTP/1.1 o superiore. Una cache deve (MUST) interpretare questo valore relativamente 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;

Il corrected_age_value può (MAY) essere utilizzato come corrected_initial_age. Nei casi in cui potrebbero esserci implementazioni di cache molto vecchie che non inseriscono correttamente Age, il corrected_initial_age può essere calcolato in modo più conservativo come

corrected_initial_age = max(apparent_age, corrected_age_value);

Il current_age di una risposta memorizzata può quindi essere calcolato aggiungendo il tempo (in secondi) dall'ultima validazione della risposta memorizzata da parte del server di origine al corrected_initial_age.

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

4.2.4 Serving Stale Responses (Servizio di risposte obsolete)

Una risposta "obsoleta (Stale)" è quella che ha informazioni di scadenza esplicite o consente il calcolo della scadenza euristica e non è fresca secondo il calcolo nella sezione 4.2.

Una cache non deve (MUST NOT) generare una risposta obsoleta se è proibita da una direttiva esplicita nel protocollo (ad esempio, da una direttiva di risposta no-cache, una direttiva di risposta must-revalidate, o una direttiva di risposta s-maxage o proxy-revalidate applicabile; vedere la sezione 5.2.2).

Una cache non deve (MUST NOT) generare una risposta obsoleta a meno che la cache non sia disconnessa o sia esplicitamente consentito dal client o dal server di origine (ad esempio, dalla direttiva di richiesta max-stale nella sezione 5.2.1, da una direttiva di estensione definita da [RFC5861], o per configurazione secondo un contratto fuori banda).

4.3 Validation (Validazione)

Quando una cache ha una o più risposte memorizzate per un URI richiesto ma non può servire nessuna di esse (ad esempio, perché non sono fresche o non può essere selezionata una adatta; vedere la sezione 4.1), può utilizzare il meccanismo di richiesta condizionale (vedere la sezione 13 di [HTTP]) in una richiesta inoltrata per dare al successivo server in ingresso l'opportunità di selezionare una risposta memorizzata valida da utilizzare, aggiornando i metadati memorizzati nel processo, o di sostituire la/le risposta/e memorizzata/e con una nuova risposta. Questo processo è noto come "validazione (Validating)" o "rivalidazione (Revalidating)" della risposta memorizzata.

4.3.1 Sending a Validation Request (Invio di una richiesta di validazione)

Quando si genera una richiesta condizionale per la validazione, una cache inizia con una richiesta che sta tentando di soddisfare o -- se sta avviando indipendentemente una richiesta -- sintetizza una richiesta utilizzando una risposta memorizzata copiando il metodo, l'URI di destinazione e i campi di intestazione della richiesta identificati dal campo di intestazione Vary (sezione 4.1).

Quindi aggiorna quella richiesta con uno o più campi di intestazione di precondizione. Questi contengono metadati del validatore ottenuti dalle risposte memorizzate per lo stesso URI. Tipicamente, questo includerà solo risposte memorizzate con la stessa chiave di cache, anche se una cache è autorizzata a validare le risposte che non può selezionare utilizzando i campi di intestazione della richiesta presentati (vedere la sezione 4.1).

Il destinatario quindi confronta i campi di intestazione di precondizione per determinare se una risposta memorizzata è equivalente a una rappresentazione corrente della risorsa.

Un tale validatore è il timestamp fornito in un campo di intestazione Last-Modified (vedere la sezione 8.8.2 di [HTTP]), che può essere utilizzato in un campo di intestazione If-Modified-Since per la validazione della risposta, o in un campo di intestazione If-Unmodified-Since o If-Range per la selezione della rappresentazione (cioè, il client si riferisce specificamente a una rappresentazione ottenuta in precedenza con quel timestamp).

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

Quando si genera una richiesta condizionale per la validazione, una cache:

• Deve (MUST) inviare l'entity-tag pertinente (utilizzando If-Match, If-None-Match o If-Range) se viene fornito un entity-tag nella risposta memorizzata in fase di validazione.

• Dovrebbe (SHOULD) inviare il valore Last-Modified (utilizzando If-Modified-Since) se la richiesta non è per un sottointervallo, viene validata una singola risposta memorizzata e quella risposta contiene un valore Last-Modified.

• Può (MAY) inviare il valore Last-Modified (utilizzando If-Unmodified-Since o If-Range) se la richiesta è per un sottointervallo, viene validata una singola risposta memorizzata e quella risposta contiene solo un valore Last-Modified (invece di un entity-tag).

Nella maggior parte dei casi, entrambi i validatori saranno generati nelle richieste di validazione della cache, anche quando gli entity-tag sono chiaramente superiori, per consentire agli intermediari più vecchi che non comprendono le precondizioni degli entity-tag di rispondere appropriatamente.

4.3.2 Handling a Received Validation Request (Gestione di una richiesta di validazione ricevuta)

Ogni client in una catena di richieste può avere la propria cache, quindi è comune che una cache di un intermediario riceva richieste condizionali da altre cache (in uscita). Allo stesso modo, alcuni user agent effettuano richieste condizionali per limitare il trasferimento di dati alle rappresentazioni modificate di recente o per completare recuperi parziali.

Se una cache riceve una richiesta che può essere soddisfatta riutilizzando una risposta memorizzata 200 (OK) o 206 (Partial Content) (secondo la sezione 4), la cache dovrebbe (SHOULD) valutare qualsiasi campo di intestazione condizionale applicabile ricevuto in quella richiesta rispetto ai validatori corrispondenti contenuti nella risposta memorizzata.

Una cache non deve (MUST NOT) valutare campi di intestazione condizionali che si applicano solo a un server di origine, si verificano in una richiesta la cui semantica non può essere soddisfatta con una risposta in cache, o si verificano in una richiesta per una risorsa di destinazione per la quale non ha una risposta memorizzata; tali precondizioni potrebbero essere destinate a qualche altro server (in ingresso).

La corretta valutazione di una richiesta condizionale da parte di una cache dipende dai campi di intestazione di precondizione ricevuti e dalla loro precedenza. In sintesi, i campi di intestazione condizionali If-Match e If-Unmodified-Since non sono applicabili a una cache, e If-None-Match ha la precedenza su If-Modified-Since. Vedere la sezione 13.2.2 di [HTTP] per una specifica completa della precedenza delle precondizioni.

Una richiesta contenente un campo di intestazione If-None-Match (vedere la sezione 13.1.2 di [HTTP]) indica che il client desidera validare una o più delle proprie risposte memorizzate rispetto alla risposta memorizzata selezionata dalla cache (secondo la sezione 4).

Se un campo di intestazione If-None-Match non è presente, una richiesta contenente un campo di intestazione If-Modified-Since (vedere la sezione 13.1.3 di [HTTP]) indica che il client desidera validare una o più delle proprie risposte memorizzate per data di modifica.

Se una richiesta contiene un campo di intestazione If-Modified-Since e un campo di intestazione Last-Modified non è presente in una risposta memorizzata, la cache dovrebbe (SHOULD) utilizzare il valore del campo Date della risposta memorizzata (o il momento in cui la risposta memorizzata è stata ricevuta, se non è presente alcun campo Date) per valutare la condizione.

Una cache che implementa risposte parziali alle richieste di intervallo (come definito nella sezione 14.2 di [HTTP]) dovrà anche valutare un campo di intestazione If-Range ricevuto (vedere la sezione 13.1.5 di [HTTP]) rispetto alla risposta selezionata dalla cache.

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

4.3.3 Handling a Validation Response (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 memorizzata può essere aggiornata e riutilizzata; vedere la sezione 4.3.4.

• Una risposta completa (cioè, una con contenuto) indica che nessuna delle risposte memorizzate nominate nella richiesta condizionale è adatta. Invece, la cache deve (MUST) utilizzare la risposta completa per soddisfare la richiesta. La cache può (MAY) memorizzare tale risposta completa, soggetta ai suoi vincoli (vedere la sezione 3).

• Tuttavia, se una cache riceve una risposta 5xx (Server Error) mentre tenta di validare una risposta, può inoltrare quella risposta al client richiedente o agire come se il server non avesse risposto. In quest'ultimo caso, la cache può (MAY) inviare una risposta precedentemente memorizzata, soggetta ai suoi vincoli per farlo (vedere la sezione 4.2.4), o riprovare la richiesta di validazione.

4.3.4 Freshening Stored Responses upon Validation (Aggiornamento delle risposte memorizzate alla validazione)

Quando una cache riceve una risposta 304 (Not Modified), deve identificare la/le risposta/e memorizzata/e adatta/e per l'aggiornamento con le nuove informazioni e quindi farlo.

L'insieme iniziale di risposte memorizzate da aggiornare è quello che avrebbe potuto essere scelto per questa richiesta -- cioè, quelle che soddisfano i requisiti nella sezione 4, ad eccezione dell'ultimo requisito che deve essere fresca, autorizzata a essere servita obsoleta o appena validata.

L'insieme iniziale di risposte memorizzate viene quindi ulteriormente filtrato dalla prima delle seguenti corrispondenze:

• Se la nuova risposta contiene uno o più "validatori forti (Strong Validators)" (vedere la sezione 8.8.1 di [HTTP]), allora ciascuno di questi validatori forti identifica una rappresentazione selezionata per l'aggiornamento. Tutte le risposte memorizzate nell'insieme iniziale che hanno uno degli stessi validatori forti sono identificate per l'aggiornamento. Se nessuna nell'insieme iniziale contiene almeno uno degli stessi validatori forti, la cache non deve (MUST NOT) utilizzare la nuova risposta per aggiornare alcuna risposta memorizzata.

• Se la nuova risposta non contiene validatori forti ma contiene uno o più "validatori deboli (Weak Validators)", e quei validatori corrispondono a uno dell'insieme iniziale di risposte memorizzate, allora la più recente di quelle risposte memorizzate corrispondenti è identificata per l'aggiornamento.

• Se la nuova risposta non contiene alcuna forma di validatore (come nel caso in cui un client genera una richiesta If-Modified-Since da una fonte diversa dal campo di intestazione di risposta Last-Modified), e c'è solo una risposta memorizzata nell'insieme iniziale, e quella risposta memorizzata manca anche di un validatore, allora quella risposta memorizzata è identificata per l'aggiornamento.

Per ciascuna risposta memorizzata identificata, la cache deve (MUST) aggiornare i suoi campi di intestazione con i campi di intestazione forniti nella risposta 304 (Not Modified), come da sezione 3.2.

4.3.5 Freshening Responses with HEAD (Aggiornamento delle risposte con HEAD)

Una risposta al metodo HEAD è identica a quella che sarebbe una richiesta equivalente effettuata con GET, tranne che non viene inviato alcun contenuto. Questa proprietà di una risposta HEAD può essere utilizzata per invalidare o aggiornare una risposta GET in cache se il meccanismo di richiesta GET condizionale più efficiente non è disponibile (a causa dell'assenza di validatori nella risposta memorizzata) o quando non si desidera la trasmissione del contenuto anche se è stato modificato.

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

Per ciascuna risposta memorizzata che avrebbe potuto essere selezionata, se la risposta memorizzata e la risposta HEAD hanno valori corrispondenti per tutti i campi di validatore ricevuti (ETag e Last-Modified) e, se la risposta HEAD ha un campo di intestazione Content-Length, il suo valore corrisponde a quello della risposta memorizzata, la cache dovrebbe (SHOULD) aggiornare la risposta memorizzata come descritto di seguito; altrimenti, la cache dovrebbe (SHOULD) considerare la risposta memorizzata come obsoleta.

Se la cache aggiorna una risposta memorizzata con metadati da una risposta HEAD, la cache deve (MUST) aggiornare la risposta memorizzata con i campi di intestazione forniti nella risposta HEAD (vedere la sezione 3.2).

4.4 Invalidating Stored Responses (Invalidazione delle risposte memorizzate)

Poiché i metodi di richiesta non sicuri (vedere la sezione 9.2.1 di [HTTP]) come PUT, POST o DELETE hanno il potenziale di modificare lo stato sul server di origine, le cache intermedie devono invalidare le risposte memorizzate per mantenere il loro contenuto aggiornato.

Quando una cache riceve una risposta con codice di stato non di errore a un metodo di richiesta non sicuro (inclusi i metodi la cui sicurezza è sconosciuta), la cache deve (MUST) invalidare l'URI di destinazione (vedere la sezione 7.1 di [HTTP]).

Quando una cache riceve una risposta con codice di stato non di errore a un metodo di richiesta non sicuro (inclusi i metodi la cui sicurezza è sconosciuta), la cache può (MAY) invalidare altri URI. In particolare, gli URI nei campi di intestazione di risposta Location e Content-Location (se presenti) sono candidati per l'invalidazione; altri URI potrebbero essere scoperti da meccanismi non specificati in questo documento. Tuttavia, una cache non deve (MUST NOT) attivare l'invalidazione in queste condizioni se l'origine (vedere la sezione 4.3.1 di [HTTP]) dell'URI da invalidare differisce da quella dell'URI di destinazione (vedere la sezione 7.1 di [HTTP]). Ciò aiuta a prevenire attacchi denial-of-service.

"Invalidare (Invalidate)" significa che la cache rimuoverà tutte le risposte memorizzate il cui URI di destinazione corrisponde all'URI fornito o le contrassegnerà come "non valide (Invalid)" e bisognose di validazione obbligatoria prima di poter essere inviate in risposta a una richiesta successiva.

Una "risposta non di errore (Non-Error Response)" è una con un codice di stato 2xx (Successful) o 3xx (Redirection).

Si noti che ciò non garantisce l'invalidazione di tutte le risposte appropriate a livello globale; le richieste che cambiano lo stato invalideranno solo le risposte nelle cache che attraversano.