4.3. Validazione (Validation)
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 una direttiva di richiesta lo vieta), può utilizzare il meccanismo di richiesta condizionale [RFC7232] nella richiesta inoltrata per dare al server di origine l'opportunità di selezionare una risposta memorizzata valida da utilizzare, aggiornando i metadati memorizzati nel processo, o di sostituire la o le risposte memorizzate con una nuova risposta. Questo processo è noto come "validazione" o "rivalidazione" della risposta memorizzata.
4.3.1. Invio di una richiesta di validazione (Sending a Validation Request)
Quando genera una richiesta condizionale per la validazione, una cache inizia con una richiesta che sta tentando di soddisfare oppure (se sta avviando la richiesta in modo indipendente) sintetizza una richiesta utilizzando una risposta memorizzata copiando il metodo, l'URI di destinazione e i campi di intestazione di richiesta pertinenti.
Successivamente aggiorna quella richiesta con uno o più campi di intestazione di precondizione. Questi contengono metadati di validatore (Sezione 2.3 di [RFC7232]) presi dalla o dalle risposte memorizzate in fase di validazione. Tipicamente, questo includerà i valori dei campi Last-Modified e/o ETag della risposta memorizzata.
La cache può quindi inviare la richiesta condizionale al server di origine (o, potenzialmente, a una cache a valle elencata in un campo di intestazione Via).
4.3.2. Gestione di una richiesta di validazione ricevuta (Handling a Received Validation Request)
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). Allo stesso modo, alcuni client potrebbero avere disallineamenti dell'orologio o altri problemi che li portano a generare richieste condizionali senza comprenderle, o tali richieste potrebbero essere generate da un'implementazione che utilizza librerie HTTP sottostanti.
Ciò significa che servire una risposta 304 (Not Modified) o 412 (Precondition Failed) a una richiesta condizionale non può essere assunto che implichi che il client comprenda tali risposte, o che abbia una copia in cache (anche se ne ha una, potrebbe essere stata rimossa).
Quando una cache riceve una richiesta che include un campo validatore (come un campo di intestazione If-None-Match), NON DEVE (MUST NOT) restituire una risposta 304 (Not Modified) a meno che non sia certa che la risposta memorizzata che è l'oggetto della richiesta condizionale sia la risposta di validazione più recente ricevuta da monte. In particolare, gli intermediari devono verificare che i validatori della risposta memorizzata (valori dei campi ETag e Last-Modified, se presenti) siano identici byte per byte a quelli presentati nella richiesta condizionale.
Si noti che una cache non è tenuta a eseguire tale controllo quando non ha una risposta memorizzata (cioè, sta eseguendo il caching "on-demand").
Una cache NON DEVE (MUST NOT) inviare una risposta 304 (Not Modified) in risposta a una richiesta che contiene un campo di intestazione di precondizione If-None-Match o If-Modified-Since la cui condizione viene valutata come falsa, poiché il client non sarebbe in grado di costruire una risposta valida dalla risposta memorizzata della cache.
Invece, una cache che riceve una richiesta condizionale e che ha una risposta memorizzata adatta per essere servita in risposta, farà una delle seguenti:
- invierà una risposta 304 (Not Modified) se la risposta memorizzata è fresca (Sezione 4.2), o se è stata validata con successo (Sezione 4.3), o
- inoltrerà la richiesta verso il server di origine con la propria richiesta condizionale che tenta di validare la risposta memorizzata.
In quest'ultimo caso, la cache includerà un validatore nella richiesta inoltrata. La richiesta inoltrata DEVE (MUST) utilizzare l'insieme più recente di validatori associati alla risposta memorizzata.