Immaginiamo che una biblioteca modifichi sul sito l’orario di oggi, ma alcuni visitatori continuino a vedere quello precedente. Occorre prima distinguere le cause possibili: l’originale sul server non è stato aggiornato, il browser ha riutilizzato una risposta memorizzata oppure un server intermedio ha fornito una vecchia versione? Aggiornare più volte la schermata, da solo, non rivela quale passaggio sia responsabile.
Una cache HTTP conserva le risposte ricevute e le riutilizza quando le condizioni lo permettono. Questo articolo collega le istruzioni di memorizzazione e riconvalida di Cache-Control a ETag e alle risposte 304, attraverso un orario pubblico immaginario. Gli scambi seguenti sono esempi abbreviati, non misure eseguite su una biblioteca reale o su un server specifico. L’obiettivo è spiegare quali risposte debbano poter essere riutilizzate e quando, anziché prescrivere di eliminare tutte le cache.
1. Separare memorizzazione, verifica e condivisione
Leggendo una politica di cache, annotate tre domande distinte: si può conservare la risposta, si può usare subito la copia nella richiesta successiva e la si può condividere tra utenti? Il permesso di memorizzare non equivale a riutilizzare sempre; verificarne l’attualità non autorizza la condivisione. Lo standard della cache HTTP RFC 9111 definisce queste condizioni con direttive diverse. Qui consideriamo direttive di risposta senza un argomento aggiuntivo contenente nomi di campi.
| Domanda da decidere | Direttiva di risposta pertinente | Significato da distinguere |
|---|---|---|
| È vietato memorizzare la risposta? | no-store | Vieta la conservazione per un successivo riutilizzo |
| Bisogna verificare prima del riutilizzo? | no-cache | La conservazione è possibile, ma il riutilizzo richiede una validazione riuscita |
| Più utenti possono condividere la risposta? | private | Esclude la conservazione nelle cache condivise senza vietarla anche in una cache privata |
Per esempio, se un orario pubblico cambia spesso allo stesso indirizzo, si può valutare il requisito di controllare la copia prima dell’uso. Una schermata personalizzata differisce già dall’orario nelle condizioni di condivisione. private riguarda le cache condivise; non sostituisce accesso e controlli delle autorizzazioni. Riunire impostazioni con scopi diversi in una frase può portare a scegliere il pubblico sbagliato per le informazioni mentre si tenta di migliorare la velocità.
Nella tabella delle politiche, scrivete anche la ragione delle direttive. Indicate se l’orario è informazione pubblica che richiede controllo delle modifiche, se il logo è un file dal contenuto fisso o se lo stesso indirizzo contiene dati personali diversi. La tabella è un punto di partenza per classificare risposte effettive, non una configurazione pronta per tutti i siti. Distinguete anche l’archivio interessato, per esempio browser o CDN.
2. Non scegliere no-cache e no-store soltanto dal nome
È facile leggere no-cache come un divieto di memorizzazione. In una risposta, però, richiede di validare la copia prima di riutilizzarla. Se il server conferma che non è cambiata, il corpo conservato può essere usato di nuovo. no-store, invece, indica di non conservare questa risposta. Cambiano sia ciò che si può tenere sia ciò che va verificato nella richiesta seguente: non aspettatevi quindi lo stesso comportamento.
Nel caching, fresh indica uno stato in cui la politica consente il riutilizzo senza ulteriori validazioni. Non garantisce che il gestore non abbia modificato l’originale nel frattempo. Se max-age stabilisce un intervallo di riutilizzo, una risposta già memorizzata può continuare a essere scelta anche dopo una modifica dell’originale entro quell’intervallo. Stabilite prima il ritardo di aggiornamento accettabile e collegatelo alle direttive. Non copiate una lunga durata arbitraria come soluzione universale alle prestazioni.
La guida alla cache HTTP di MDN spiega che aggiungere no-store a una nuova risposta non elimina le risposte precedenti già conservate per la stessa URL. Se la vecchia copia è ancora utilizzabile e non si richiede quella nuova, potrebbe non arrivare neppure il nuovo header. Non considerate no-store una cancellazione completa della cache o una condizione sufficiente per la privacy. Controllate anche la vita delle risposte esistenti e le procedure di aggiornamento delle cache gestibili.
3. Seguire una nuova visita con ETag e 304
Supponiamo che l’indirizzo immaginario /hours.json segnali inizialmente la chiusura alle 18:00. Il seguente formato esplicativo HTTP/1.1 conserva solo le parti necessarie e omette altri header richiesti in una risposta reale. hours-v1 è un identificatore della rappresentazione scelto dal server per l’esempio, non una formula per gli orari né l’hash effettivo di un file.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
ETag: "hours-v1"
{"closes":"18:00"}Se il browser ha memorizzato questa risposta, può poi inviare il valore ETag in If-None-Match con una richiesta condizionale. Se la condizione corrisponde alla rappresentazione attuale selezionata dal server e questa è considerata invariata, il server risponde 304 Not Modified. Il blocco successivo è una registrazione abbreviata di richiesta e risposta in sequenza. Non mostra l’invio di un nuovo JSON degli orari dopo il 304.
GET /hours.json HTTP/1.1
Host: library.example
If-None-Match: "hours-v1"
HTTP/1.1 304 Not Modified
Cache-Control: no-cache
ETag: "hours-v1"Come descrive la spiegazione di ETag di MDN, il client usa allora il corpo conservato. Un 304 non contiene un nuovo corpo, ma richiesta e validazione comportano comunque comunicazione. Se il gestore cambia la chiusura alle 19:00 e cambia anche la rappresentazione del server, è ragionevole attendersi un 200 con corpo e identificatore nuovi per la vecchia condizione. no-cache non significa ottenere sempre 304 né eliminare le interrogazioni al database.
Controllate la corrispondenza tra contenuto e identificatore più che il solo codice di stato. Se il contenuto cambia ma il server mantiene il vecchio ETag, la validazione può dare un risultato errato. Al contrario, identificatori sempre diversi per contenuti identici possono aumentare le ritrasmissioni del corpo. Verificate sul server il rapporto tra generazione e rappresentazione selezionata. La semplice presenza di un ETag non prova che l’implementazione sia corretta.
4. Distinguere documenti variabili e risorse con nomi nuovi
Un documento che cambia contenuto alla stessa URL, come l’orario, può richiedere una strategia diversa da loghi e script a cui si assegna un nuovo nome quando cambiano. Se il logo passa da logo.a1.png a logo.b2.png, il nuovo documento deve puntare al nuovo indirizzo. Inserire un identificatore nel nome ma sovrascrivere il contenuto del vecchio file viola l’impegno di gestire insieme contenuto e indirizzo.
Caricare un file nuovo non fa sì, da solo, che i visitatori ne richiedano l’indirizzo. Se l’HTML ricevuto continua a indicare il vecchio logo, la vecchia risorsa può essere riutilizzata. Esaminate quindi anche il percorso di aggiornamento del documento che la richiama, non soltanto le impostazioni della risorsa. Anziché imporre la stessa durata di conservazione a documenti e risorse, bisogna poter spiegare quanto ritardo sia accettabile per ciascuno.
Durante la distribuzione possono coesistere brevemente documenti vecchi e nuovi. Pubblicare il documento nuovo prima che le risorse siano pronte o cancellare troppo presto quelle vecchie produce problemi distinti. Nell’esempio immaginario si possono verificare sia l’esistenza dei file richiamati dal documento nuovo sia l’accessibilità di quelli usati dai documenti esistenti. Cambiare nome ai file è uno strumento di progettazione della cache, non una soluzione automatica a ogni problema di ordine di distribuzione o ripristino.
5. Verificare un’ipotesi per volta nel pannello Network
Per un controllo diretto, registrate prima una situazione di riferimento con la cache consentita. Osservate insieme URL esatta e parametri di query, versione dell’orario visualizzata, stato della risposta, If-None-Match nella richiesta e Cache-Control ed ETag nella risposta. Header di richiesta e risposta esprimono condizioni di soggetti diversi anche quando i nomi coincidono: annotate quale lato avete letto. La documentazione Network di Chrome DevTools spiega come distinguerli in Headers.
| Situazione di prova immaginaria | Registrazioni da esaminare insieme | Conclusione prematura da evitare |
|---|---|---|
| Richiedere di nuovo lo stesso orario | Richiesta condizionale, stato e orario mostrato | Un 304 significa assenza totale di comunicazione |
| Richiedere dopo aver modificato l’originale | Corpo nuovo, ETag e URL effettivamente richiesta | Il messaggio di salvataggio riuscito prova l’aggiornamento per ogni utente |
| Richiedere con la cache del browser disattivata | Differenza tra primo download e visita successiva normale | Il risultato coincide con le prestazioni abituali di una nuova visita |
| Tornare con il pulsante Indietro | Nuova richiesta eventualmente avvenuta e schermata ripristinata | La schermata visibile prova una nuova validazione HTTP |
Provate poi a disattivare la cache del browser come condizione separata. L’opzione Disable cache di Chrome vale mentre DevTools è aperto: registrate quindi insieme apertura degli strumenti e impostazione. È utile per studiare il primo download, ma non equivale a verificare come una visita ordinaria riusi le copie. Senza questa annotazione, download sempre nuovi possono far pensare che la cache non funzioni. Conservate le condizioni della prova per tornare al confronto con la cache consentita.
Durante l’osservazione, evitate numerose modifiche e richieste contemporanee. Controllate prima una visita senza cambiamenti, poi modificate una sola voce oraria e osservate la risposta. Cambiare insieme URL del documento, impostazioni del server e nomi dei file rende difficile attribuire l’effetto. Se il 200 o il 304 previsto non compare, rileggete prima la richiesta e la risposta reali invece di aggiungere configurazioni.
6. Controllare altri archivi e criteri di completamento
Disattivare la cache HTTP del browser non implica eliminare una CDN davanti al server o altri percorsi di conservazione dell’applicazione. Verificate separatamente se un service worker gestisce la richiesta, quale risposta seleziona un intermediario e se l’applicazione mantiene a schermo dati già ricevuti. Vedere la stessa URL non significa che ogni livello usi la stessa copia.
Distinguete anche il ritorno indietro da una nuova richiesta HTTP. Quando il browser ripristina la schermata di una sessione precedente, la riconvalida attesa può non apparire persino con no-cache. Interpretarlo subito come prova che il server ha ignorato l’header rischia di individuare una causa sbagliata. Annotate separatamente se si è verificata una richiesta in una nuova navigazione, nel ricaricamento e nel ritorno, senza riunire fenomeni diversi in un unico problema.
Il completamento dell’esempio non consiste soltanto in una buona percentuale di risposte trovate in cache. Verificate l’uso corretto della copia invariata, l’apparizione delle novità entro il tempo accettato e la condivisione con i destinatari giusti. Orari di modifica e osservazione, condizioni e corpo effettivo permettono ad altri di riprodurre il caso. Numeri di velocità migliori non soddisfano l’esigenza iniziale se l’orario sbagliato rimane visibile troppo a lungo.
Nell’uso operativo, rivedete le politiche per tipo di risposta insieme alle procedure di aggiornamento e ripristino. Non copiate le direttive di documenti pubblici su risposte personali e non interpretate una validazione riuscita come controllo di autorizzazione completato. Gli header comunicano regole di conservazione e riutilizzo. Saper spiegare cosa è stato memorizzato e quali verifiche hanno portato alla schermata attuale permette una diagnosi più precisa delle schermate obsolete.