Perché sia ​​no-cache che no-store dovrebbero essere usati nella risposta HTTP?

Mi è stato detto di impedire la fuga di informazioni sugli utenti, solo "no-cache" in risposta non è sufficiente. è necessario anche "no-store".

Cache-Control: no-cache, no-store

Dopo aver letto questa specifica http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html , non sono ancora sicuro del perché.

La mia comprensione attuale è che è solo per il server cache intermedio. Anche se "no-cache" è in risposta, il server cache intermedio può comunque salvare il contenuto in una memoria non volatile. Il server cache intermedio deciderà se utilizzare il contenuto salvato per la richiesta successiva. Tuttavia, se "no-store" è nella risposta, il server cache intermedio non dovrebbe archiviare il contenuto. Quindi è più sicuro.

C'è qualche altra ragione per cui abbiamo bisogno sia di "no-cache" che di "no-store"?

Devo chiarire che no-cachenon significa non memorizzare nella cache . In effetti, significa "riconvalida con il server" prima di utilizzare qualsiasi risposta memorizzata nella cache che potresti avere, su ogni richiesta.

must-revalidate, d'altra parte, deve essere riconvalidato solo quando la risorsa è considerata obsoleta.

Se il server dice che la risorsa è ancora valida, la cache può rispondere con la sua rappresentazione, alleviando così la necessità per il server di inviare nuovamente l'intera risorsa.

no-storeè effettivamente la direttiva ` ` full do not cache '' e ha lo scopo di impedire la memorizzazione della rappresentazione in qualsiasi forma di cache.

Dico qualunque cosa, ma nota questo nelle specifiche HTTP RFC 2616:

I buffer di cronologia POSSONO memorizzare tali risposte come parte del loro normale funzionamento

Ma questo è omesso dalla più recente specifica HTTP RFC 7234 nel tentativo di renderlo no-storepiù forte, vedere:

http://tools.ietf.org/html/rfc7234#section-5.2.1.5

In determinate circostanze, IE6 memorizzerà ancora i file nella cache anche quando si Cache-Control: no-cachetrova nelle intestazioni delle risposte.

Il W3C afferma dino-cache :

Se la direttiva no-cache non specifica un nome di campo, una cache NON DEVE usare la risposta per soddisfare una richiesta successiva senza riconvalidare con successo con il server di origine.

Nella mia applicazione, se hai visitato una pagina con l' no-cacheintestazione, poi sei disconnesso e poi hai colpito di nuovo nel tuo browser, IE6 avrebbe comunque preso la pagina dalla cache (senza una nuova richiesta di convalida al server). L'aggiunta no-storenell'intestazione ha interrotto l'operazione. Ma se prendi il W3C in parola, in realtà non c'è modo di controllare questo comportamento:

I buffer di cronologia POSSONO memorizzare tali risposte come parte del loro normale funzionamento.

Le differenze generali tra la cronologia del browser e la normale memorizzazione nella cache HTTP sono descritte in una sottosezione specifica delle specifiche .

Dalla specifica HTTP 1.1 :

no-store :

Lo scopo del no-storeè quello di impedire il rilascio o la conservazione involontaria di informazioni sensibili (ad esempio, sui nastri di backup). La direttiva no-store si applica all'intero messaggio e PU essere inviata in una risposta o in una richiesta. Se inviata in una richiesta, una cache NON DEVE memorizzare alcuna parte di questa richiesta o di qualsiasi risposta ad essa. Se inviata in una risposta, una cache NON DEVE memorizzare alcuna parte di questa risposta o della richiesta che l'ha provocata. Questa direttiva si applica sia alle cache non condivise che a quelle condivise. "NON DEVE archiviare" in questo contesto significa che la cache NON DEVE archiviare intenzionalmente le informazioni in una memoria non volatile e DEVE fare il massimo sforzo per rimuovere le informazioni dalla memoria volatile il più rapidamente possibile dopo averle inoltrate. Anche quando questa direttiva è associata a una risposta, gli utenti potrebbero memorizzare esplicitamente tale risposta al di fuori del sistema di memorizzazione nella cache (ad esempio, con una finestra di dialogo "Salva con nome"). I buffer di cronologia POSSONO memorizzare tali risposte come parte del loro normale funzionamento. Lo scopo di questa direttiva è soddisfare i requisiti dichiarati di alcuni utenti e autori di servizi che sono preoccupati per il rilascio accidentale di informazioni tramite accessi imprevisti alle strutture di dati della cache. Sebbene l'uso di questa direttiva possa migliorare la privacy in alcuni casi, avvertiamo che NON è in alcun modo un meccanismo affidabile o sufficiente per garantire la privacy. In particolare, le cache dannose o compromesse potrebbero non riconoscere o obbedire a questa direttiva e le reti di comunicazione potrebbero essere vulnerabili alle intercettazioni. I buffer di cronologia POSSONO memorizzare tali risposte come parte del loro normale funzionamento. Lo scopo di questa direttiva è soddisfare i requisiti dichiarati di alcuni utenti e autori di servizi che sono preoccupati per il rilascio accidentale di informazioni tramite accessi imprevisti alle strutture di dati della cache. Sebbene l'uso di questa direttiva possa migliorare la privacy in alcuni casi, avvertiamo che NON è in alcun modo un meccanismo affidabile o sufficiente per garantire la privacy. In particolare, cache dannose o compromesse potrebbero non riconoscere o obbedire a questa direttiva e le reti di comunicazione potrebbero essere vulnerabili alle intercettazioni. I buffer di cronologia POSSONO memorizzare tali risposte come parte del loro normale funzionamento. Lo scopo di questa direttiva è soddisfare i requisiti dichiarati di alcuni utenti e autori di servizi che sono preoccupati per il rilascio accidentale di informazioni tramite accessi imprevisti alle strutture di dati della cache. Sebbene l'uso di questa direttiva possa migliorare la privacy in alcuni casi, avvertiamo che NON è in alcun modo un meccanismo affidabile o sufficiente per garantire la privacy. In particolare, cache dannose o compromesse potrebbero non riconoscere o obbedire a questa direttiva e le reti di comunicazione potrebbero essere vulnerabili alle intercettazioni. Sebbene l'uso di questa direttiva possa migliorare la privacy in alcuni casi, avvertiamo che NON è in alcun modo un meccanismo affidabile o sufficiente per garantire la privacy. In particolare, cache dannose o compromesse potrebbero non riconoscere o obbedire a questa direttiva e le reti di comunicazione potrebbero essere vulnerabili alle intercettazioni. Sebbene l'uso di questa direttiva possa migliorare la privacy in alcuni casi, avvertiamo che NON è in alcun modo un meccanismo affidabile o sufficiente per garantire la privacy. In particolare, cache dannose o compromesse potrebbero non riconoscere o obbedire a questa direttiva e le reti di comunicazione potrebbero essere vulnerabili alle intercettazioni.

Se vuoi impedire tutto il caching (es. Forzare un ricaricamento quando usi il pulsante Indietro) devi:

• no-cache per IE

• nessun negozio per Firefox

Ci sono le mie informazioni su questo qui:

http://blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/

no-storenon dovrebbe essere necessario in situazioni normali e può nuocere sia alla velocità che all'usabilità. È inteso per l'uso dove la risposta HTTP contiene informazioni così sensibili che non dovrebbe mai essere scritta su una cache del disco, indipendentemente dagli effetti negativi che crea per l'utente.

Come funziona:

• Normalmente, anche se un programma utente come un browser determina che una risposta non deve essere memorizzata nella cache, può comunque memorizzarla nella cache del disco per motivi interni al programma utente. Questa versione può essere utilizzata per funzioni come "visualizza sorgente", "indietro", "informazioni sulla pagina" e così via, dove l'utente non ha necessariamente richiesto di nuovo la pagina, ma il browser non la considera una nuova visualizzazione di pagina e avrebbe senso offrire la stessa versione che l'utente sta attualmente visualizzando.

• L'utilizzo no-storeimpedirà la memorizzazione di tale risposta, ma ciò potrebbe influire sulla capacità del browser di fornire "Visualizza origine", "Indietro", "Informazioni sulla pagina" e così via senza fare una nuova richiesta separata per il server, il che è indesiderabile. In altre parole, l'utente può provare a visualizzare la fonte e se il browser non l'ha tenuta in memoria, gli verrà detto che non è possibile o causerà una nuova richiesta al server. Pertanto, no-storedeve essere utilizzato solo quando l'esperienza utente impedita di queste funzionalità che non funziona correttamente o rapidamente è controbilanciata dall'importanza di garantire che il contenuto non sia archiviato nella cache.

La mia comprensione attuale è che è solo per il server cache intermedio. Anche se "no-cache" è in risposta, il server cache intermedio può comunque salvare il contenuto in una memoria non volatile.

Questo non è corretto. I server cache intermedi compatibili con HTTP 1.1 obbediranno alle istruzioni no-cachee must-revalidate, assicurando che il contenuto non venga memorizzato nella cache. L'utilizzo di queste istruzioni assicurerà che la risposta non venga memorizzata nella cache da alcuna cache intermedia e che tutte le richieste successive vengano inviate al server di origine.

Se il server cache intermedio non supporta HTTP 1.1, sarà necessario utilizzarlo Pragma: no-cachee sperare per il meglio. Nota che se non supporta HTTP 1.1, no-storeè comunque irrilevante.

Se un sistema di memorizzazione nella cache implementa correttamente no-store, non avrai bisogno di no-cache. Ma non tutti lo fanno. Inoltre, alcuni browser implementano no-cache come se fosse no-store. Pertanto, sebbene non strettamente richiesto, è probabilmente più sicuro includerli entrambi.

Si noti che Internet Explorer dalla versione 5 fino alla 8 genererà un errore quando si tenta di scaricare un file servito tramite https e l'invio del server Cache-Control: no-cacheo le Pragma: no-cacheintestazioni.

Vedi http://support.microsoft.com/kb/812935/en-us

L'uso di Cache-Control: no-storee Pragma: privatesembra essere la cosa più vicina che funziona ancora.

Per Chrome, nessuna cache viene utilizzata per ricaricare la pagina durante una nuova visita, ma la memorizza comunque nella cache se torni indietro nella cronologia (pulsante Indietro). Per ricaricare la pagina anche per la cronologia, usa no-store. IE necessita di una riconvalida necessaria per funzionare in tutte le occasioni.

Quindi, per essere sicuro di evitare tutti i bug e le interpretazioni errate che uso sempre

Cache-Control: no-store, no-cache, must-revalidate

se voglio assicurarmi che si ricarichi.

Inizialmente abbiamo utilizzato no-cache molti anni fa e abbiamo riscontrato alcuni problemi con contenuti obsoleti con alcuni browser ... Sfortunatamente, non ricordare le specifiche.

Da allora abbiamo deciso di utilizzare SOLO il no-store. Da allora non ho mai guardato indietro o avuto un singolo problema con contenuti obsoleti da parte di alcun browser o intermediario.

Questo spazio è certamente dominato dalla realtà delle implementazioni rispetto a ciò che è stato scritto in varie RFC. Molti proxy in particolare tendono a pensare di fare un lavoro migliore nel "migliorare le prestazioni" sostituendo la politica che dovrebbero seguire con la propria.

Solo per peggiorare le cose, in alcune situazioni, no-cache non può essere utilizzato, ma no-store può:

http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/

OWASP discute questo:

Qual è la differenza tra le direttive di controllo della cache: no-cache e no-store?

La direttiva no-cache in una risposta indica che la risposta non deve essere utilizzata per servire una richiesta successiva, cioè la cache non deve visualizzare una risposta con questa direttiva impostata nell'intestazione, ma deve consentire al server di servire la richiesta. La direttiva no-cache può includere alcuni nomi di campo; in tal caso la risposta può essere mostrata dalla cache ad eccezione dei nomi dei campi specificati che dovrebbero essere serviti dal server. La direttiva no-store si applica all'intero messaggio e indica che la cache non deve memorizzare nessuna parte della risposta o qualsiasi richiesta che l'ha richiesta.

Sono totalmente al sicuro con queste direttive?

No. Ma generalmente, usa sia Cache-Control: no-cache, no-store e Pragma: no-cache, oltre a Expires: 0 (o una data GMT sufficientemente retrodatata come l'epoca UNIX). I tipi di contenuto non html come pdf, documenti word, fogli di calcolo Excel, ecc. Spesso vengono memorizzati nella cache anche quando sono impostate le direttive di controllo della cache di cui sopra (sebbene ciò vari in base alla versione e all'uso aggiuntivo di must-revalidate, pre-check = 0, post-check = 0, max-age = 0 e s-maxage = 0 in pratica a volte possono causare almeno la cancellazione di file alla chiusura del browser in alcuni casi a causa di stranezze del browser e implementazioni HTTP). Inoltre, la funzione "Completamento automatico" consente a un browser di memorizzare nella cache qualsiasi cosa l'utente digiti in un campo di input di un modulo. Per verificarlo, il tag del modulo o i singoli tag di input devono includere l'attributo "Autocomplete =" Off "". Però,

Fonte qui .