Cache-Control: no-store non è no-cache. Nell’RFC 9111, giugno 2022, riletto il 19 ottobre 2026, no-store sulla risposta vieta di memorizzare. no-cache senza argomenti vieta di riusare senza una validazione riuscita. Si può tenere la copia e chiedere conferma. Non è la stessa frase. L’RFC rende obsoleto l’RFC 7234. Autori: Roy T. Fielding, Mark Nottingham, Julian Reschke.
In breve: no-store vale per cache private e condivise, e non è un meccanismo di privacy. no-cache non significa «non salvare». private è una terza direttiva: la cache condivisa non memorizza, quella privata può. must-understand, in certi casi, fa ignorare no-store. Non è l’HTTP 429.
Due divieti diversi
Sezione 5.2.2.4, forma senza argomenti: la risposta MUST NOT essere usata per soddisfare un’altra richiesta senza inoltrarla per la validazione e senza ricevere una risposta riuscita. Il server può così impedire l’uso anche alle cache configurate per consegnare risposte stantie. La copia può esistere. Non può essere servita alla cieca.
La forma con argomenti, una lista di nomi di campi, è un’altra regola: la cache MAY riusare la risposta, se quei campi sono esclusi dalla risposta successiva oppure se la risposta è stata rivalidata con successo. I nomi non sono limitati ai campi di questo RFC e non distinguono maiuscole e minuscole. Il mittente SHOULD NOT mandare la forma a token: va la quoted-string. La nota dell’RFC è secca: spesso le cache trattano la forma qualificata come se fosse quella senza argomenti. La gestione speciale non è molto implementata. Chi conta su no-cache="Set-Cookie" sta citando una frase che l’RFC stesso dice poco applicata.
Sezione 5.2.2.5: no-store sulla risposta indica che una cache MUST NOT memorizzare alcuna parte della richiesta immediata né della risposta, e MUST NOT usare la risposta per soddisfare un’altra richiesta. Non c’è la scappatoia della rivalidazione. Il divieto è non avere la copia.
| Direttiva | Sezione | La cache può tenere la risposta? |
|---|---|---|
no-cache senza argomenti | 5.2.2.4 | Sì, ma non la serve senza validazione riuscita |
no-store sulla risposta | 5.2.2.5 | No: non memorizza e non riusa |
private senza argomenti | 5.2.2.7 | La cache condivisa no. Quella privata può |
no-store sulla richiesta | 5.2.1.5 | Non memorizza questa richiesta né la sua risposta. Non tocca una copia già in cache |
Cosa vuol dire «non memorizzare»
La stessa sezione glossa il MUST NOT store: la cache non deve memorizzare l’informazione di proposito in uno storage non volatile, e deve fare un tentativo ragionevole di toglierla dallo storage volatile il prima possibile dopo averla inoltrata. Vale per le cache private e per quelle condivise.
Il capoverso successivo toglie l’illusione: la direttiva non è un meccanismo affidabile né sufficiente per la privacy. Cache malevole o compromesse possono non riconoscerla. La rete può essere intercettata. Mettere no-store su una pagina di login non sostituisce TLS, e non è una prova che il disco del proxy sia pulito.
La direttiva sulla richiesta non cancella la copia già fatta
Sulla richiesta, sezione 5.2.1.4, no-cache indica una preferenza del client: non usare una risposta memorizzata senza validazione riuscita sull’origine. Non è un ordine di cancellazione.
no-store sulla richiesta, sezione 5.2.1.5, è più stretto: la cache MUST NOT memorizzare alcuna parte di questa richiesta né di alcuna risposta a essa. Stessa glossa su volatile e non volatile, stessa frase sulla privacy. Poi l’eccezione che si dimentica: se la richiesta viene soddisfatta da una cache, la direttiva no-store della richiesta non si applica alla risposta già memorizzata. Il client che manda no-store non sta svuotando la cache. Sta dicendo di non creare una copia nuova di questo giro. Se la copia c’era, l’RFC non la fa cancellare da questa richiesta.
private e must-understand
private senza argomenti, sezione 5.2.2.7: una cache condivisa MUST NOT memorizzare la risposta, perché è intesa per un solo utente. Una cache privata MAY memorizzarla, nei limiti della sezione 3, anche se altrimenti non sarebbe memorizzabile in modo euristico. Non è no-store: il browser dell’utente può tenere la copia. Il proxy condiviso no.
must-understand, sezione 5.2.2.3, limita la memorizzazione alle cache che capiscono e rispettano i requisiti di quello status code. Una risposta che la contiene SHOULD contenere anche no-store. Quando una cache che implementa must-understand la riceve, SHOULD ignorare no-store se capisce e implementa i requisiti di cache di quello status. La sezione 5.2.2.5 lo richiama: in quelle circostanze must-understand scavalca no-store. Un no-store accanto a must-understand non è, per quelle cache, il divieto che sembra.
Niente di questo è il 429 con Retry-After, e niente è la bfcache del browser. Sono altri meccanismi, già raccontati a parte. Il cluster è Operatività.
Errori da evitare
Leggere
no-cachecome «non scrivere su disco». L’RFC vieta il riuso senza validazione, non la memorizzazione.Credere che
no-storerenda la risposta privata. L’RFC dice il contrario, in entrambe le sezioni, richiesta e risposta.Mandare
no-storenella richiesta per cancellare una risposta già in cache. Se la cache soddisfa la richiesta, la direttiva non si applica a quella copia.Contare sulla forma
no-cache="Nome-Campo". La nota dice che spesso viene trattata come la forma senza argomenti.Ignorare
must-understand. Per una cache che lo implementa,no-storesulla stessa risposta può essere ignorato.
In sintesi
RFC 9111, giugno 2022: no-cache senza argomenti permette di tenere la risposta e vieta di servirla senza una validazione riuscita. no-store vieta di memorizzare richiesta e risposta e di riusarle. private ferma la cache condivisa, non quella privata. no-store sulla richiesta non cancella ciò che era già memorizzato. Non è un sigillo di privacy e non è un 429.
Foto di copertina: Esquilo, «PDC server room», Wikimedia Commons, CC BY-SA 3.0. È una sala macchine, non un diagramma di Cache-Control.
