Por que no-cache e no-store devem ser usados ​​na resposta HTTP?

Disseram-me para impedir o vazamento de informações do usuário, apenas "sem cache" em resposta não é suficiente. "no-store" também é necessário.

Cache-Control: no-cache, no-store

Depois de ler esta especificação http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html , ainda não sei bem o porquê.

Meu entendimento atual é que é apenas para servidor de cache intermediário. Mesmo se "sem cache" estiver em resposta, o servidor de cache intermediário ainda poderá salvar o conteúdo em armazenamento não volátil. O servidor de cache intermediário decidirá se está usando o conteúdo salvo para a solicitação a seguir. No entanto, se "no-store" estiver na resposta, o servidor de cache intermediário não deve armazenar o conteúdo. Então, é mais seguro.

Existe alguma outra razão pela qual precisamos de "no-cache" e "no-store"?

Devo esclarecer que no-cachenão significa não armazenar em cache . De fato, significa "revalidar com o servidor" antes de usar qualquer resposta em cache que você possa ter, a cada solicitação.

must-revalidate, por outro lado, só precisa revalidar quando o recurso é considerado obsoleto.

Se o servidor disser que o recurso ainda é válido, o cache poderá responder com sua representação, aliviando a necessidade de o servidor reenviar todo o recurso.

no-storeé efetivamente a diretiva full do não cache e visa impedir o armazenamento da representação em qualquer forma de cache.

Eu digo tudo, mas observe isso na especificação HTTP RFC 2616:

Os buffers de história PODEM armazenar essas respostas como parte de sua operação normal

Mas isso é omitido da especificação HTTP RFC 7234 mais recente em uma tentativa potencial de tornar no-storemais forte, consulte:

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

Sob certas circunstâncias, o IE6 ainda armazenará em cache os arquivos, mesmo quando Cache-Control: no-cacheestiver nos cabeçalhos de resposta.

O W3C declarano-cache :

Se a diretiva sem cache não especificar um nome de campo, um cache NÃO DEVE usar a resposta para atender a uma solicitação subseqüente sem uma revalidação bem-sucedida com o servidor de origem.

No meu aplicativo, se você visitasse uma página com o no-cachecabeçalho, desconectasse e depois retornasse ao seu navegador, o IE6 ainda pegaria a página do cache (sem uma nova solicitação / validação para o servidor). Adicionando no no-storecabeçalho parou de fazê-lo. Mas se você aceitar o W3C, não há realmente nenhuma maneira de controlar esse comportamento:

Buffers de história podem armazenar essas respostas como parte de sua operação normal.

As diferenças gerais entre o histórico do navegador e o cache HTTP normal são descritas em uma subseção específica da especificação .

Na especificação HTTP 1.1 :

sem loja :

O objetivo do -storeA diretiva é impedir a liberação ou retenção inadvertida de informações confidenciais (por exemplo, em fitas de backup). A diretiva no-store se aplica a toda a mensagem e PODE ser enviada em uma resposta ou em uma solicitação. Se enviado em uma solicitação, um cache NÃO DEVE armazenar qualquer parte dessa solicitação ou qualquer resposta a ela. Se enviado em uma resposta, um cache NÃO DEVE armazenar nenhuma parte dessa resposta ou da solicitação que a provocou. Esta diretiva se aplica a caches não compartilhados e compartilhados. "NÃO DEVE armazenar" neste contexto significa que o cache NÃO DEVE armazenar intencionalmente as informações no armazenamento não volátil e DEVE fazer uma tentativa de remover as informações do armazenamento volátil o mais rápido possível após o encaminhamento. Mesmo quando esta diretiva está associada a uma resposta, os usuários podem armazenar explicitamente essa resposta fora do sistema de armazenamento em cache (por exemplo, com uma caixa de diálogo "Salvar como"). Buffers de história podem armazenar essas respostas como parte de sua operação normal. O objetivo desta diretiva é atender aos requisitos declarados de certos usuários e autores de serviços preocupados com liberações acidentais de informações por meio de acessos imprevistos a estruturas de dados em cache. Embora o uso desta diretiva possa melhorar a privacidade em alguns casos, advertimos que NÃO é de forma alguma um mecanismo confiável ou suficiente para garantir a privacidade. Em particular, caches mal-intencionados ou comprometidos podem não reconhecer ou obedecer a essa diretiva, e as redes de comunicação podem estar vulneráveis ​​à interceptação. Buffers de história podem armazenar essas respostas como parte de sua operação normal. O objetivo desta diretiva é atender aos requisitos declarados de certos usuários e autores de serviços preocupados com liberações acidentais de informações por meio de acessos imprevistos a estruturas de dados em cache. Embora o uso desta diretiva possa melhorar a privacidade em alguns casos, advertimos que NÃO é de forma alguma um mecanismo confiável ou suficiente para garantir a privacidade. Em particular, caches mal-intencionados ou comprometidos podem não reconhecer ou obedecer a essa diretiva, e as redes de comunicação podem estar vulneráveis ​​à interceptação. Buffers de história podem armazenar essas respostas como parte de sua operação normal. O objetivo desta diretiva é atender aos requisitos declarados de certos usuários e autores de serviços preocupados com liberações acidentais de informações por meio de acessos imprevistos a estruturas de dados em cache. Embora o uso desta diretiva possa melhorar a privacidade em alguns casos, advertimos que NÃO é de forma alguma um mecanismo confiável ou suficiente para garantir a privacidade. Em particular, caches mal-intencionados ou comprometidos podem não reconhecer ou obedecer a essa diretiva, e as redes de comunicação podem estar vulneráveis ​​à interceptação. Embora o uso desta diretiva possa melhorar a privacidade em alguns casos, advertimos que NÃO é de forma alguma um mecanismo confiável ou suficiente para garantir a privacidade. Em particular, caches mal-intencionados ou comprometidos podem não reconhecer ou obedecer a essa diretiva, e as redes de comunicação podem estar vulneráveis ​​à interceptação. Embora o uso desta diretiva possa melhorar a privacidade em alguns casos, advertimos que NÃO é de forma alguma um mecanismo confiável ou suficiente para garantir a privacidade. Em particular, caches mal-intencionados ou comprometidos podem não reconhecer ou obedecer a essa diretiva, e as redes de comunicação podem estar vulneráveis ​​à interceptação.

Se você deseja impedir todo o armazenamento em cache (por exemplo, forçar uma recarga ao usar o botão Voltar), é necessário:

• sem cache para o IE

• sem loja para Firefox

Aqui estão minhas informações sobre isso:

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

no-storenão deve ser necessário em situações normais e pode prejudicar a velocidade e a usabilidade. Destina-se ao uso em que a resposta HTTP contém informações tão sensíveis que nunca devem ser gravadas em um cache de disco, independentemente dos efeitos negativos criados para o usuário.

Como funciona:

• Normalmente, mesmo que um agente do usuário, como um navegador, determine que uma resposta não deve ser armazenada em cache, ele ainda poderá armazená-la no cache do disco por razões internas ao agente do usuário. Essa versão pode ser utilizada para recursos como "visualizar fonte", "voltar", "informações da página" etc., onde o usuário não solicitou a página necessariamente novamente, mas o navegador não a considera uma nova visualização da página e faria sentido exibir a mesma versão que o usuário está visualizando no momento.

• O uso no-storeimpedirá que essa resposta seja armazenada, mas isso pode afetar a capacidade do navegador de fornecer "fonte de visualização", "voltar", "informações da página" e assim por diante, sem fazer uma nova solicitação separada para o servidor, o que é indesejável. Em outras palavras, o usuário pode tentar visualizar a fonte e, se o navegador não a mantiver na memória, será informado que isso não é possível ou causará uma nova solicitação ao servidor. Portanto, no-storesó deve ser usado quando a experiência do usuário prejudicada desses recursos não funcionar corretamente ou rapidamente for superada pela importância de garantir que o conteúdo não seja armazenado no cache.

Meu entendimento atual é que é apenas para servidor de cache intermediário. Mesmo se "sem cache" estiver em resposta, o servidor de cache intermediário ainda poderá salvar o conteúdo em armazenamento não volátil.

Isto está incorreto. Servidores de cache intermediários compatíveis com HTTP 1.1 obedecerão às instruções no-cachee must-revalidate, garantindo que o conteúdo não seja armazenado em cache. O uso dessas instruções garantirá que a resposta não seja armazenada em cache por nenhum cache intermediário e que todas as solicitações subsequentes sejam enviadas de volta ao servidor de origem.

Se o servidor de cache intermediário não suportar HTTP 1.1, será necessário usar Pragma: no-cachee esperar o melhor. Observe que, se ele não suporta HTTP 1.1, no-storeé irrelevante de qualquer maneira.

Se um sistema de cache implementa corretamente o no-store, você não precisaria do no-cache. Mas nem todos fazem. Além disso, alguns navegadores implementam nenhum cache como se fosse no-store. Portanto, embora não seja estritamente necessário, é provavelmente mais seguro incluir os dois.

Observe que o Internet Explorer da versão 5 até 8 lançará um erro ao tentar baixar um arquivo veiculado via https e o envio Cache-Control: no-cacheou Pragma: no-cachecabeçalhos do servidor .

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

O uso de Cache-Control: no-storee Pragma: privateparece ser a coisa mais próxima que ainda funciona.

Para o chrome, nenhum cache é usado para recarregar a página em uma nova visita, mas ainda a armazena em cache se você voltar ao histórico (botão voltar). Para recarregar a página também para o histórico, use no-store. O IE precisa revalidar para funcionar em todas as ocasiões.

Então, para ter certeza de evitar todos os erros e interpretações erradas que eu sempre uso

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

se eu quiser ter certeza de que ele é recarregado.

Originalmente, usamos o sem cache há muitos anos e tivemos alguns problemas com conteúdo obsoleto em determinados navegadores ... Infelizmente, não lembro das especificações.

Desde então, decidimos APENAS o uso de nenhuma loja. Nunca olhou para trás ou teve um único problema com o conteúdo obsoleto de qualquer navegador ou intermediários desde então.

Esse espaço é certamente dominado pela realidade das implementações versus o que foi escrito em várias RFCs. Muitos proxies em particular tendem a pensar que fazem um trabalho melhor de "melhorar o desempenho", substituindo a política que deveriam seguir pela sua.

Apenas para piorar as coisas, em algumas situações, o cache não pode ser usado, mas o no-store pode:

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

OWASP discute isso:

Qual é a diferença entre as diretivas de controle de cache: sem cache e sem armazenamento?

A diretiva sem cache em uma resposta indica que a resposta não deve ser usada para atender a uma solicitação subseqüente, ou seja, o cache não deve exibir uma resposta que tenha essa diretiva definida no cabeçalho, mas deve permitir que o servidor atenda à solicitação. A diretiva sem cache pode incluir alguns nomes de campo; nesse caso, a resposta pode ser mostrada no cache, exceto pelos nomes de campos especificados que devem ser veiculados no servidor. A diretiva sem armazenamento se aplica a toda a mensagem e indica que o cache não deve armazenar nenhuma parte da resposta ou qualquer solicitação que a solicite.

Estou totalmente seguro com essas diretivas?

Não. Mas, geralmente, use o Cache-Control: no-cache, no-store e Pragma: no-cache, além de Expira em: 0 (ou uma data GMT suficientemente antiga, como na época do UNIX). Tipos de conteúdo não html, como pdf, documentos do Word, planilhas do Excel, etc. geralmente são armazenados em cache, mesmo quando as diretivas de controle de cache acima estão definidas (embora isso varie por versão e uso adicional de revalidação obrigatória, verificação prévia = 0, verificação posterior) = 0, idade máxima = 0 e s-maxage = 0 na prática às vezes podem resultar pelo menos na exclusão do arquivo após o fechamento do navegador, em alguns casos devido a peculiaridades do navegador e implementações HTTP). Além disso, o recurso 'preenchimento automático' permite que um navegador armazene em cache o que o usuário digitar no campo de entrada de um formulário. Para verificar isso, a tag de formulário ou as tags de entrada individuais devem incluir o atributo 'Autocomplete = "Off"'. Contudo,

Fonte aqui .