4.3.3. Handling a Validation Response (Gestione di una risposta di validazione)

La gestione 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 Sezione 4.3.4.
Una risposta completa (cioè una con un corpo di payload) 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, soggetta ai suoi vincoli (vedere Sezione 3).
Tuttavia, se una cache riceve una risposta 5xx (Server Error) mentre tenta di validare una risposta, può inoltrare questa risposta al client richiedente, o agire come se il server non fosse riuscito a rispondere. In quest'ultimo caso, la cache PUÒ (MAY) inviare una risposta precedentemente memorizzata (vedere Sezione 4.2.4).

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

Quando una cache riceve una risposta 304 (Not Modified), DEVE (MUST) aggiornare i campi di intestazione della risposta memorizzata con i campi di intestazione forniti nella risposta 304, secondo RFC 7232, Sezione 4.1.

La cache DEVE (MUST) anche utilizzare la risposta memorizzata aggiornata per soddisfare la richiesta che ha causato la validazione e PUÒ (MAY) utilizzarla per soddisfare altre richieste.

Quando aggiorna un valore di campo di intestazione, la cache DEVE (MUST) eliminare qualsiasi campo di intestazione Warning nella risposta memorizzata con warn-code 1xx (vedere Sezione 5.5) e DEVE (MUST) aggiungere alla risposta memorizzata aggiornata qualsiasi campo di intestazione Warning nella risposta 304.

4.3.5. Freshening Responses via HEAD (Aggiornamento delle risposte tramite HEAD)

Una risposta al metodo HEAD è identica a ciò che sarebbe stata una richiesta equivalente fatta con GET, tranne per il fatto che manca un corpo. Questa proprietà delle risposte HEAD consente a una cache di aggiornare una risposta memorizzata senza trasferire l'intero contenuto della risposta. Pertanto, una cache PUÒ (MAY) utilizzare una risposta HEAD per aggiornare una risposta GET memorizzata nella cache se la risposta HEAD ha valori di campo Last-Modified e/o ETag che corrispondono a quelli della risposta GET memorizzata.

Quando aggiorna una risposta memorizzata utilizzando una risposta HEAD, la cache DEVE (MUST) aggiornare i campi di intestazione della risposta memorizzata con i valori dei campi di intestazione forniti nella risposta HEAD.

4.4. Invalidation (Invalidazione)

Lo scopo dell'invalidazione della cache è eliminare le risposte il cui valore di risposta effettivo (non i campi di intestazione) è probabilmente significativamente diverso dalla risposta invalidata, evitando così confusione se le due vengono presentate come alternative.

Quando una cache riceve una richiesta con un metodo che può comportare un aggiornamento delle risposte memorizzate (ad esempio, PUT, POST o DELETE; vedere Sezione 4.2.1 di [RFC7231]), DEVE (MUST) considerare tutte le risposte memorizzate per l'URI di richiesta effettivo (Sezione 5.5 di [RFC7230]) come invalidate, insieme a quelle per gli URI nei campi di intestazione di risposta Location e Content-Location (se presenti).

Tuttavia, una cache NON DEVE (MUST NOT) invalidare un URI che appare nei campi di intestazione di risposta Location o Content-Location se il codice di stato della risposta è un reindirizzamento e il componente host in quell'URI differisce dall'host dell'URI di richiesta effettivo.

Una cache DEVE (MUST) invalidare l'URI di richiesta effettivo (Sezione 5.5 di [RFC7230]) quando riceve una risposta non di errore a una richiesta con un metodo la cui semantica implica che lo stato della risorsa di destinazione potrebbe essere stato modificato (ad esempio, PUT, POST, DELETE e PATCH).