Por tanto não-cache e no interior da loja deve ser usado em HTTP resposta?

Question

Me disseram para evitar user-info vazamento, apenas "no-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 , eu ainda não estou muito certo porquê.

O meu entendimento atual é que ele é apenas para servidor de cache intermediário. Mesmo se "no-cache" é uma resposta, servidor de cache intermediário ainda pode salvar o conteúdo para armazenamento não volátil. O servidor de cache intermediário irá decidir se usar o conteúdo guardado para seguir pedido. No entanto, se "no interior da loja" está na resposta, o sever cache intermediário não é suposto para armazenar o conteúdo. Então, é mais seguro.

Existe alguma outra razão precisamos de ambos "no-cache" e "não-store"?

Answer 1

Devo esclarecer que no-cache não significa não de cache . Na verdade, isso significa "revalidate com o servidor" antes de usar qualquer resposta em cache que possa ter, em cada solicitação.

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

Se o servidor diz que o recurso ainda é válido, então o cache pode responder com a sua representação, aliviando assim a necessidade do servidor para reenviar o recurso inteiro.

no-store é efetivamente a plena não de cache directiva e se destina a evitar que o armazenamento da representação em qualquer forma de cache de qualquer tipo.

Eu digo que seja, mas note isso no RFC 2616 HTTP spec:

buffers a história pode armazenar tais respostas como parte de sua operação normal

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

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

Answer 2

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

O W3C estados de no-cache :

Se a diretiva no-cache não especifique um nome de campo, então um cache NÃO DEVE usar a resposta para satisfazer uma pedido subsequente sem sucesso revalidação com o servidor de origem.

Na minha aplicação, se você visitou uma página com o cabeçalho no-cache, em seguida, sair e, em seguida, bater de volta em seu navegador, o IE6 ainda iria pegar a página do cache (sem a / validar pedido novo para o servidor). Adicionando no cabeçalho no-store parou fazê-lo. Mas se você tomar o W3C em sua palavra, não há realmente nenhuma maneira de controlar esse comportamento:

buffers a história pode armazenar tais respostas como parte de sua operação normal.

diferenças gerais entre o histórico do navegador e o cache HTTP normal são descritos em uma sub-seção específica da especificação .

Answer 3

A partir da HTTP especificação 1.1 :

no-store :

O objetivo do no-store directiva é impedir a liberação inadvertida ou retenção de informações sensíveis (por exemplo, em fitas de backup). A directiva no-store se aplica a toda a mensagem, e poderão ser enviados em uma resposta ou em uma solicitação. Se for enviado um pedido, um cache NÃO DEVE armazenar qualquer parte de qualquer este pedido ou qualquer resposta a ele. Se for enviado em uma resposta, um cache NÃO DEVE armazenar qualquer parte de qualquer esta resposta ou o pedido que provocou isso. Esta directiva aplica-se a ambos os caches não compartilhados e partilhados. "NÃO DEVE armazenar" neste meio contexto que a MUST cache não armazenam intencionalmente a informação no armazenamento não volátil, e deve fazer uma tentativa de melhor esforço para remover as informações de armazenamento volátil tão prontamente quanto possível após encaminhá-lo. Mesmo quando esta directiva está associada a uma resposta, os usuários podem armazenar explicitamente tais fora resposta um do sistema de cache (por exemplo, uma caixa de diálogo "Salvar como"). buffers a história pode armazenar tais respostas como parte de sua operação normal. O objectivo desta directiva é o de atender aos requisitos informados de determinados usuários e autores de serviços que estão preocupados com as descargas acidentais de informações através de acessos não previstas estruturas de dados cache. Embora o uso desta directiva pode melhorar a privacidade em alguns casos, que advertem que ele não é de forma alguma um mecanismo confiável ou suficiente para garantir a privacidade. Em particular, caches maliciosos ou comprometidos podem não reconhecer ou obedecer a esta directiva, e redes de comunicações podem estar vulneráveis ??a espionagem.

Answer 4

Se você quer evitar todas cache (por exemplo, forçar uma recarga ao usar o botão voltar) que precisa:

• no-cache para o IE

• no-store para o Firefox

Não é meu informações sobre esta aqui:

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

Answer 5

no-store não deve ser necessário em situações normais, e pode prejudicar a velocidade e usabilidade. Pretende-se para o uso onde a resposta HTTP contém informação tão sensível que nunca deve ser gravado em um cache de disco em tudo, independentemente dos efeitos negativos que cria para o usuário.

Como funciona:

• Normalmente, mesmo se um agente de usuário como um navegador determina que uma resposta não deve ser armazenado em cache, ele ainda pode armazená-lo para o cache de disco por razões internas ao agente do usuário. Esta versão pode ser utilizada para características como "view source", "back", "info página", e assim por diante, onde o usuário não tem necessariamente solicitado a página novamente, mas o navegador não considerá-lo uma nova exibição de página e não faria sentido para servir a mesma versão que o usuário está vendo atualmente.

• Usando no-store vai impedir que a resposta a ser armazenado, mas isso pode afetar a capacidade do navegador para dar "view source", "back", "info página" e assim por diante, sem fazer um novo pedido, separado para o servidor , o que é indesejável. Em outras palavras, o usuário pode tentar a visualização da fonte e se o navegador não mantê-lo na memória, eles vão quer ser dito isso não for possível, ou ele vai causar um novo pedido para o servidor. Portanto, no-store só deve ser usado quando a experiência do usuário impedido destes recursos não funcionando corretamente ou rapidamente é compensado pela importância de garantir o conteúdo não é armazenado em cache.

O meu entendimento atual é que ele é apenas para servidor de cache intermediário. Mesmo se "no-cache" é uma resposta, servidor de cache intermediário ainda pode salvar o conteúdo para armazenamento não volátil.

Isso é incorreto. servidores de cache intermediários compatíveis com HTTP 1.1 vai obedecer as instruções no-cache e must-revalidate, garantindo que o conteúdo não é armazenado em cache. Usando estas instruções irá garantir que a resposta não está em cache por qualquer cache intermediário, e que todos os pedidos subsequentes são enviados de volta ao servidor de origem.

Se o servidor de cache intermediário não suporta HTTP 1.1, então você vai precisar usar Pragma: no-cache e esperar o melhor. Nota que, se ele não suporta HTTP 1.1 no-store então é assim mesmo irrelevante.

Answer 6

Se um sistema de cache corretamente implementos no interior da loja, então você não precisa de no-cache. Mas nem todos fazem. Além disso, alguns navegadores implementar no-cache como se fosse no interior da loja. Assim, embora não seja estritamente necessário, é provavelmente mais seguro para incluir ambos.

Answer 7

Para cromo, sem cache é usado para recarregar a página em uma re-visita, mas ainda armazena em cache-lo se você voltar na história (botão voltar). Para recarregar a página para a história-back, bem como, o uso no interior da loja. IE precisa de must-revalidar a trabalhar em todas as ocasiões.

Então, só para ter a certeza de evitar todos os erros e más interpretações Eu sempre uso

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

Se eu quero ter certeza que recarrega.

Answer 8

Note que o Internet Explorer a partir da versão 5 até 8 irá lançar um erro ao tentar baixar um arquivo servido via https e o servidor de envio Cache-Control: no-cache ou Pragma: no-cache cabeçalhos.

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

O uso de Cache-Control: no-store e Pragma: private parece ser a coisa mais próxima que ainda funciona.

Answer 9

Originalmente nós usado no-cache há muitos anos e fez para alguns problemas com conteúdo obsoleto com determinados navegadores ... não me lembro os detalhes infelizmente.

Nós tínhamos uma vez liquidada em apenas o uso de no-store. Nunca olhou para trás ou tinha um único problema com conteúdo obsoleto por qualquer navegador ou intermediários desde então.

Este espaço é certamente dominado pela realidade de implementações vs o que acontece ter sido escrito em vários RFCs. Muitos proxies, em particular, tendem a pensar que fazer um trabalho melhor de "melhorar o desempenho", substituindo a política que é suposto estar a seguir com a sua própria.

Answer 10

Apenas para tornar as coisas ainda piores, em algumas situações, no-cache não pode ser usado, mas nenhuma loja pode:

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

Answer 11

OWASP discute o seguinte:

Qual é a diferença entre as directivas de controle de cache: no-cache, e no interior da loja

A directiva no-cache em uma resposta indica que a resposta não deve ser utilizado para servir uma solicitação subseqüente ou seja, o cache não deve exibir uma resposta que tem este conjunto directiva no cabeçalho, mas deve deixar o servidor servir o pedido. A directiva no-cache pode incluir alguns nomes de campo; caso em que a resposta pode ser mostrado a partir do cache exceto para os nomes dos campos especificados que devem ser servidas a partir do servidor. A directiva no-store se aplica a toda a mensagem e indica que o cache não deve armazenar qualquer parte da resposta ou qualquer pedido que pediu para ele.

Am I totalmente seguro com estas directivas?

No. Mas, geralmente, usar tanto Cache-Control: no-cache, no interior da loja e Pragma: no-cache, além de Expira: 0 (ou uma data GMT suficientemente retroativo, tais como a época UNIX). Não html tipos de conteúdo, como pdf, documentos do Word, planilhas Excel, etc muitas vezes ficam em cache, mesmo quando as directivas de controle de cache acima são definidos (embora isso varia de acordo com a versão e uso adicional de must-revalidar, pré-check = 0, pós-check = 0, maxage = 0, e s-maxage = 0 na prática, às vezes pode resultar, pelo menos na exclusão do arquivo no encerramento do navegador em alguns casos, devido a peculiaridades do navegador e HTTP implementações). Além disso, o recurso de 'Autocomplete' permite que um navegador para cache de qualquer que seja o usuário digita em um campo de entrada de um formulário. Para verificar isso, a marca de formulário ou as tags de entrada individuais deve incluir 'Autocomplete = 'Off'' atributo. No entanto, deve-se notar que este atributo é não-padrão (embora seja suportado pelos principais navegadores) para que ele irá quebrar a validação XHTML.

aqui .