Per un documento pubblico modificabile, scegli la convalida se vuoi che i lettori ricevano contenuti aggiornati e che le pagine invariate restino riutilizzabili. Scegli no-store se i requisiti di pubblicazione escludono specificamente l’archiviazione nella cache HTTP.

Questa guida è rivolta a chi gestisce un documento pubblico da un computer Mac. L’attività consiste nello scegliere una politica di risposta e poi verificarla in Terminal usando una pagina sintetica che contiene solo testo neutro, ad esempio «Guida alle forme, versione uno». Ti serve una pagina di test e l’accesso alla configurazione del suo hosting, oppure un fornitore che possa configurare le intestazioni della risposta.

Quale politica di caching è adatta al documento?

Parti dai requisiti di pubblicazione. La pagina deve essere controllata prima di ogni riutilizzo, una copia esistente può restare utilizzabile per un breve periodo oppure le cache HTTP devono evitare di archiviare la risposta? Si tratta di requisiti diversi secondo RFC 9111: HTTP Caching.

Requisito di pubblicazione Intestazione di risposta possibile Significato per una cache HTTP
Controllo prima di ogni riutilizzo Cache-Control: no-cache L’archiviazione è consentita; il riutilizzo richiede una convalida riuscita.
Consentire un breve periodo di validità Cache-Control: max-age=300, must-revalidate Il riutilizzo è consentito finché la risposta è valida; quando scade, è necessaria una convalida riuscita.
Escludere l’archiviazione della risposta Cache-Control: no-store La cache non deve archiviare la risposta né usarla per un’altra richiesta.

La finestra di cinque minuti è un esempio a scopo illustrativo, non un valore predefinito consigliato. Sceglila solo se il documento può tollerare quell’intervallo di riutilizzo. must-revalidate da solo non richiede un controllo finché la risposta è valida. Queste distinzioni seguono le direttive di risposta di RFC 9111.

Per la guida sintetica alle forme, supponi che la correzione da «tre esempi» a «quattro esempi» debba essere rilevata al recupero successivo. Parti da no-cache e da un validatore funzionante. Se il tuo requisito stabilisce invece che le cache HTTP non devono conservare questa risposta del documento, scegli no-store. Il fatto che il documento venga modificato spesso, da solo, non implica che l’archiviazione debba essere esclusa.

Prima di modificare le impostazioni, scrivi il requisito: per esempio, «Controllare il documento prima del riutilizzo». In questo modo avrai un criterio di accettazione concreto e impedirai che la politica venga determinata dal nome di un’impostazione.

Cosa serve perché la convalida funzioni?

Un validatore identifica la versione già ricevuta dal client. ETag fornisce un tag dell’entità; Last-Modified fornisce una data e un’ora di modifica. RFC 9110 raccomanda di inviare i validatori disponibili per i recuperi riusciti dei documenti, preferendo sia un tag dell’entità forte sia una data di modifica. Consulta HTTP Semantics, validators e 200 OK.

Questi sono esempi illustrativi di campi di intestazione della risposta, non codice di configurazione del server. Presuppongono che il corpo della risposta sia la guida sintetica alle forme:

Cache-Control: no-cache
ETag: "shape-guide-v1"

In una richiesta successiva, il client può inviare If-None-Match: \"shape-guide-v1\". Se il tag corrisponde ancora alla rappresentazione selezionata, la richiesta condizionale GET riceve 304 Not Modified, senza corpo della risposta. Se il tag non corrisponde più, la normale elaborazione può restituire il documento modificato. Le regole sono riportate nella sezione di RFC 9110 sulle richieste condizionali.

Il requisito di implementazione è che il validatore segua la versione del documento. Non copiare il tag illustrativo in una configurazione permanente lasciandolo invariato dopo le modifiche. Chiedi al sistema di hosting di generare i validatori in modo coerente e di valutare le condizioni ricevute.

Quanto trasferimento può evitare una risposta invariata?

Considera un calcolo esplicitamente illustrativo: il corpo di un documento è di 80.000 byte e un client lo recupera 100 volte senza alcuna modifica. Una risposta completa seguita da 99 convalide riuscite trasferisce 80.000 byte di corpo invece di 8.000.000: una differenza di 7.920.000 byte.

Il calcolo esclude intestazioni, compressione, overhead della connessione e qualsiasi attività applicativa. Riguarda solo il trasferimento del corpo. La spiegazione di Google sul caching HTTP descrive lo stesso scambio: un validatore corrispondente consente una 304 senza corpo e il client usa i contenuti ricevuti in precedenza. Il risparmio effettivo dipende dalla frequenza con cui cambiano i documenti e dalle modalità di invio delle richieste da parte dei client.

Dove configurare la politica?

Configura la risposta HTTP generata dal servizio di hosting, dal server o dal livello di distribuzione dei contenuti. Gli esempi di intestazione qui sopra descrivono il risultato richiesto; non sono comandi universali per una piattaforma di pubblicazione.

Se il tuo editor permette di modificare solo il testo del documento, una soluzione basata sul markup non offre un controllo equivalente. Lo standard WHATWG HTML non definisce Cache-Control come una direttiva pragma http-equiv supportata e spiega che tali pragma sono in gran parte separate dalle intestazioni HTTP. Consulta HTML Standard: Pragma directives.

La soluzione supportata consiste nell’usare la configurazione documentata delle intestazioni di risposta del tuo host o nel chiedere al fornitore di implementarla. Anche la panoramica di Google sui crawler indirizza gli editori al proprio fornitore di hosting o di gestione dei contenuti per l’implementazione del caching HTTP. Una richiesta utile specifica il documento, la politica scelta e il comportamento del validatore, poi chiede come verificare la risposta effettivamente inviata.

Modificare un’opzione di una richiesta JavaScript ha un ambito più ristretto. WHATWG definisce una modalità cache di Fetch no-store che si comporta come se non ci fosse alcuna cache HTTP, mentre no-cache invia una richiesta condizionale quando esiste una risposta appropriata nella cache. Queste modalità regolano quella richiesta; impostarne una in uno script non configura la politica di risposta del server per il documento. Consulta le modalità cache dello standard Fetch.

Come verificare la convalida da un Mac?

Usa un documento pubblico sintetico di test che puoi modificare. Prima di iniziare, imposta il contenuto su «Guida alle forme, versione uno» e assicurati che vengano inviate le intestazioni di risposta scelte. Mantieni questo test separato dai documenti reali, così potrai apportare una modifica evidente e reversibile.

Apri Terminal ed esegui i comandi seguenti nella stessa sessione. Ti chiedono l’URL effettivo della pagina di test e il validatore restituito dalla pagina; non viene presunto alcun indirizzo di esempio. Fermati dopo la prima richiesta se non riesce, viene reindirizzata o restituisce qualcosa di diverso dalla risposta del documento prevista.

printf '%s\n' 'Paste the full URL of your synthetic public test page:'
IFS= read -r page_url

curl --silent --show-error --connect-timeout 5 --max-time 20 \
  --dump-header - --output /dev/null --url "$page_url"

printf '%s\n' 'Paste its ETag value exactly, including quotes:'
IFS= read -r page_etag

check_page() {
  curl --silent --show-error --connect-timeout 5 --max-time 20 \
    --dump-header - --output /dev/null \
    --header "If-None-Match: $page_etag" --url "$page_url"
}

check_page

I comandi inviano richieste GET, mostrano le intestazioni ricevute e scartano intenzionalmente il corpo della risposta. I timeout limitano la durata della connessione e del trasferimento; gli errori restano visibili. Queste opzioni sono documentate nel manuale di curl. La prima richiesta dovrebbe mostrare il valore Cache-Control scelto e un ETag. Se non è presente alcun tag, non inserirne uno inventato: prima risolvi il problema del supporto ai validatori.

Copia il valore completo del tag, comprese le virgolette circostanti e l’eventuale prefisso W/. Se la rappresentazione non è cambiata e il tag corrisponde, la richiesta condizionale dovrebbe restituire 304. Una 304 non può contenere contenuti e deve includere i metadati specificati che accompagnerebbero la risposta 200 equivalente, compresi ETag e Cache-Control quando applicabili. Consulta RFC 9110: 304 Not Modified.

Verificare una modifica mantenendo il vecchio validatore

Modifica il documento sintetico in «Guida alle forme, versione due: quattro esempi». Dopo che l’aggiornamento è arrivato alla pagina di test, mantieni il vecchio tag nella stessa sessione di Terminal ed esegui questo comando per continuare:

check_page

Per questo documento modificato appositamente, aspettati che il nuovo corpo sia disponibile con una normale risposta riuscita e un validatore aggiornato. Poi ripeti i comandi iniziali usando il nuovo tag e verifica di nuovo la versione invariata. In questo modo verifichi entrambi i casi: il rilevamento di una modifica e quello dell’assenza di modifiche.

Osservazione Passaggio diagnostico successivo
La richiesta iniziale restituisce un reindirizzamento Usa l’URL finale del documento e riavvia il test.
La richiesta condizionale per il contenuto invariato restituisce 200 Controlla di aver copiato correttamente il tag e che la gestione delle condizioni sia attiva.
Una modifica intenzionale del contenuto restituisce comunque 304 con il vecchio tag Prima di affidarti alla convalida, indaga la distribuzione degli aggiornamenti e la generazione dei validatori.
La politica effettivamente inviata differisce dalla configurazione Esamina le impostazioni di hosting e distribuzione responsabili della risposta finale.
La richiesta scade o non riesce Risolvi il problema di recupero prima di interpretare il comportamento della cache.

Questi sono spunti diagnostici, non prove di una causa specifica. La procedura verifica la risposta e lo scambio condizionale; non stabilisce come si comporterà ogni browser. Quando valuti no-store, esamina direttamente tale direttiva di risposta. Una richiesta condizionale costruita manualmente non verifica se un browser ha archiviato una risposta.

Cosa significa per Google Search?

La documentazione attuale di Google per i crawler supporta ETag con If-None-Match e Last-Modified con If-Modified-Since. Raccomanda ETag per i crawler di Google e afferma che i singoli crawler possono usare il caching in modo diverso. Consulta Overview of Google crawlers and fetchers.

La pagina dice anche che le altre direttive di caching HTTP non sono supportate e, separatamente, suggerisce max-age come possibile indicazione per un nuovo crawling insieme a Last-Modified. Considerando questo limite documentato, non dare per scontato che la politica no-store o no-cache usata dal browser determini la pianificazione dei recuperi di Googlebot. Implementa e verifica i validatori come percorso documentato per il recupero condizionale.

Google spiega che una 304 segnala ai suoi sistemi di elaborazione che i contenuti sono invariati; per la Ricerca, altrimenti non ha alcun effetto sull’indicizzazione. Anche una 200 riuscita non garantisce l’indicizzazione. Queste informazioni sono documentate in How HTTP status codes affect Google’s crawlers.

Scegli la politica adatta ai requisiti del documento e conserva le prove del test: la risposta iniziale, una risposta condizionale senza modifiche e una risposta dopo una modifica intenzionale. Per un documento pubblico che deve essere controllato prima del riutilizzo, la convalida è un punto di partenza pratico. Scegli no-store se il requisito consiste nell’escludere l’archiviazione nella cache HTTP.

Fonti