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

120

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"?

Morgan Cheng
fonte
3
no-cachenão significa o que você pensa que faz. Na verdade, significa "revalidar".
Erwan Legrand 23/03

Respostas:

77

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

Luke Puplett
fonte
18
Ainda não respondeu à pergunta: por que o no-cache e o no-store devem ser usados ​​na resposta HTTP? Não é Cache-Control: no-storesuficiente?
Franklin Yu
Existem diferenças entre os navegadores? Como este artigo da Microsoft docs.microsoft.com/en-us/iis/configuration/system.webServer/… nem menciona no-storee descreve no-cachecomo se não fizesse cache nenhum ... Estou confuso!
Roel
A resposta de Alconja é a resposta para a pergunta, especificamente. Quando respondi, o fiz apenas para esclarecer um miconceito muito comum. Por favor vote na outra resposta!
Luke Puplett 18/01/19
48

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 .

Alconja
fonte
7
quando você retorna ao seu navegador, o IE6 não pega a página do cache. Ele pega a página do buffer do histórico.
Pacerier
1
No Chrome 34 (2014), ainda é necessário definir no-storetambém. Caso contrário, o Chrome mostrará dados armazenados em cache / em buffer ao usar o botão Voltar.
caw
4
-1 porque a primeira frase implica incorretamente que é incorreto para um navegador armazenar em cache uma resposta que tenha um no-cachecabeçalho. A citação do W3C imediatamente abaixo deixa claro que esse não é o caso; em vez disso, o no-cachecabeçalho significa apenas que a resposta deve ser revalidada antes de ser reutilizada para atender solicitações subsequentes.
Mark Amery
1
A redação das especificações foi aprimorada do RFC1616 para a versão atual da família spec ( tools.ietf.org/html/rfc7230 de RFCs). uma família porque são 6 RFCs. Eles obsoletos 2616.
Arcin B
16

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.

backslash17
fonte
1
Se você já não está armazenando em cache a solicitação, isso já não impediria o armazenamento da resposta em mídia não volátil?
Lèse majesté
4
@ Lèsemajesté Na maioria das vezes não. no-cachee max-age=0diga que o item deve ser considerado obsoleto. Isso significa que ele deve ser revalidado antes de ser veiculado. Isso significa que um cache pode armazenar o arquivo e executar uma solicitação condicional à qual o servidor pode responder 304 NOT MODIFIED. Obviamente, essa é uma grande vantagem, pois o corpo da resposta não precisa ser gerado e enviado. Então, para tirar proveito desta muitos (a maioria?) Caches irá armazenar no-cacherespostas.
Kevin Cox
14

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/

HttpWatchSupport
fonte
6
Por que nenhuma loja seria suficiente para o Internet Explorer? Sua postagem no blog não explica.
Simon Lieschke
1
De qual versão do IE você está falando?
Pacerier
1
@ Pacerier, provavelmente qualquer versão do IE foi a mais recente no momento em que ele / ela escreveu o comentário. Segundo a Wikipedia, este era o IE7. Para FF, parece 3. Não são muitas as pessoas que ainda usam.
trysis
11

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.

thomasrutter
fonte
3
Estou entendendo mal algo porque o mnot.net/cache_docs/#CACHE-CONTROL está contradizendo você. Ele afirma que no-cachemantém uma atualização rígida sem sacrificar todos os benefícios do armazenamento em cache, o que significa que o cache é armazenado e usado novamente se o servidor responder com 304 Não Modificado.
Pacerier
-1: sem cache não significa que o conteúdo não pode ser armazenado em cache. Em 14.9.1 What Is Cachable, a especificação diz: "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 êxito na revalidação com o servidor de origem". ( w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9. ) Como Chris Shiflett explica, "não impede que um sistema de cache mantenha uma cópia em cache. Simplesmente requer que o sistema de cache revalide seu cache antes de para enviá-lo de volta ao cliente ". (Manual do desenvolvedor de HTTP, p 91)
james.garriss
Não acho que o que escrevi nesta resposta contrate nenhum desses dois comentários - simplesmente não falei sobre como os navegadores revalidam (por exemplo, usando If-Modified-Since / If-None-Match) porque não o vi como relevante. Eu nem tentei cobrir para que serve o cache, então estou tendo dificuldades para entender como o comentário de @ james.garriss se relaciona com a minha resposta.
thomasrutter
7

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.

james.garriss
fonte
Mas nem todos fazem. ”Precisamos de um exemplo concreto para convencer meu colega.
Franklin Yu
Esse comentário foi feito há 6 anos. Você precisará pesquisar o comportamento atual dos servidores de cache para ver o que eles estão fazendo.
James.garriss
6

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.

bassim
fonte
2
Conforme sugerido em uma resposta SO relacionada, você pode definir Cache-Control: no-store, no-cache, must-revalidatenessa ordem exata para fazê-lo funcionar. No entanto, isso não funcionou em nosso cenário, mas o que @bassim sugeriu acima fez. Obrigado!
Eirik H
6

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.

lãs
fonte
2

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.

Einstein
fonte
Eu acredito que é o Firefox que preferia o no-store.
bvdb
-1

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 .

Jan Żankowski
fonte
Isto está incorreto. no-cachediz que você não pode usá-lo sem validar com o servidor. Se sua cópia em cache ainda estiver boa, o servidor responderá com um 304 e você usará sua cópia em cache. Economiza um download de rede potencialmente grande. no-storepor outro lado, diz que você não tem permissão para armazenar em cache os dados.
Gárgula