Qual é a diferença entre o Cache-Control: max-age = 0 e sem cache?

O cabeçalho Cache-Control: max-age=0implica que o conteúdo é considerado obsoleto (e deve ser buscado novamente) imediatamente, o que é efetivamente o mesmo que Cache-Control: no-cache.

Eu tive a mesma pergunta e encontrei algumas informações em minhas pesquisas (sua pergunta surgiu como um dos resultados). Aqui está o que eu determinei ...

Existem dois lados no Cache-Controlcabeçalho. Um lado é para onde pode ser enviado pelo servidor da web (também conhecido como "servidor de origem"). O outro lado é para onde ele pode ser enviado pelo navegador (também conhecido como "user agent").

Quando enviado pelo servidor de origem

Eu acredito que max-age=0simplesmente informa aos caches (e agentes do usuário) que a resposta é obsoleta desde o início e, portanto, eles DEVEM revalidar a resposta (por exemplo, com o If-Not-Modifiedcabeçalho) antes de usar uma cópia em cache, ao passo que no-cachelhes diz que DEVEM revalidar antes de usar um cache. cópia de. De 14.9.1 O que é cache :

sem cache

... um cache NÃO DEVE usar a resposta para atender a uma solicitação subseqüente sem revalidação bem-sucedida com o servidor de origem. Isso permite que um servidor de origem impeça o armazenamento em cache, mesmo por caches configurados para retornar respostas obsoletas às solicitações do cliente.

Em outras palavras, os caches às vezes podem optar por usar uma resposta obsoleta (embora eu acredite que eles precisam adicionar um Warningcabeçalho), mas no-cachedizem que eles não têm permissão para usar uma resposta obsoleta, não importa o quê. Talvez você deseja que o DEVE comportamento -revalidate quando estatísticas de beisebol são gerados em uma página, mas você iria querer a MUST comportamento -revalidate quando você gerou a resposta a uma compra e-commerce.

Embora você esteja correto em seu comentário quando diz que no-cachenão deve impedir o armazenamento, pode ser outra diferença ao usá-lo no-cache. Me deparei com uma página, Diretivas de Controle de Cache Desmistificadas , que diz (não posso garantir sua correção):

Na prática, o IE e o Firefox começaram a tratar a diretiva sem cache como se instruísse o navegador a não armazenar em cache a página. Começamos a observar esse comportamento há cerca de um ano. Suspeitamos que essa alteração tenha sido motivada pelo uso generalizado (e incorreto) dessa diretiva para impedir o armazenamento em cache.

...

Observe que ultimamente, "cache-control: no-cache" também começou a se comportar como a diretiva "no-store".

Como um aparte, parece-me que Cache-Control: max-age=0, must-revalidatedeveria significar basicamente a mesma coisa que Cache-Control: no-cache. Então, talvez essa seja uma maneira de obter o comportamento de validação DEVEno-cache , evitando a migração aparente de no-cachepara fazer a mesma coisa que no-store(ou seja, sem armazenamento em cache)?

Quando enviado pelo agente do usuário

Acredito que a resposta de shahkalpesh se aplica ao lado do agente do usuário. Você também pode ver 13.2.6 Desambiguando várias respostas .

Se um agente do usuário envia uma solicitação com Cache-Control: max-age=0(também conhecida como "revalidação de ponta a ponta"), cada cache ao longo do caminho revalidará sua entrada de cache (por exemplo, com o If-Not-Modifiedcabeçalho) até o servidor de origem. Se a resposta for 304 (Não Modificado), a entidade em cache poderá ser usada.

Por outro lado, o envio de uma solicitação com Cache-Control: no-cache(também conhecido como "recarga de ponta a ponta") não revalida e o servidor NÃO DEVE usar uma cópia em cache ao responder.

idade máxima = 0

Isso equivale a clicar em Atualizar , o que significa fornecer a cópia mais recente, a menos que eu já possua a cópia mais recente.

sem cache

Isso pressiona Shift enquanto clica em Atualizar, o que significa que apenas refaça tudo, não importa o quê.

Pergunta antiga agora, mas se alguém encontrar isso através de uma pesquisa como eu, parece que o IE9 fará uso disso para configurar o comportamento dos recursos ao usar os botões voltar e avançar. Quando max-age = 0 é usado, o navegador usa a última versão ao visualizar um recurso em uma imprensa para trás / para frente. Se nenhum cache for usado, o recurso será recuperado.

Mais detalhes sobre o cache do IE9 podem ser vistos nesta postagem do blog em cache do msdn .

Nos meus testes recentes com o IE8 e Firefox 3.5, parece que ambos são compatíveis com RFC. No entanto, eles diferem em sua "simpatia" com o servidor de origem. O IE8 trata as no-cacherespostas com a mesma semântica que max-age=0,must-revalidate. O Firefox 3.5, no entanto, parece tratar no-cachecomo equivalente a no-store, o que é péssimo para desempenho e uso de largura de banda.

O Squid Cache, por padrão, parece nunca armazenar nada com um no-cachecabeçalho, assim como o Firefox.

Meu conselho seria definir public,max-age=0recursos não confidenciais que você deseja verificar em cada solicitação, mas ainda permitir os benefícios de desempenho e largura de banda do armazenamento em cache. Para itens por usuário com a mesma consideração, use private,max-age=0.

Eu evitaria o uso de no-cacheinteiramente, pois parece que ele foi bastardizado por alguns navegadores e caches populares para o equivalente funcional de no-store.

Além disso, não emule Akamai e Limelight. Embora eles basicamente executem matrizes de cache em massa como seu principal negócio, e devam ser especialistas, eles realmente têm interesse em fazer com que mais dados sejam baixados de suas redes. O Google também pode não ser uma boa opção para emulação. Eles parecem usar max-age=0ou no-cachealeatoriamente, dependendo do recurso.

idade máxima
    Quando um cache intermediário é forçado, por meio de uma diretiva max-age = 0, a revalidar 
sua própria entrada de cache e o cliente forneceu seu próprio validador na solicitação, o 
O validador fornecido pode diferir do validador atualmente armazenado com a entrada de cache. 
Nesse caso, o cache PODE usar um validador para fazer seu próprio pedido sem 
afetando a transparência semântica. 

    No entanto, a escolha do validador pode afetar o desempenho. A melhor abordagem é para o
cache intermediário para usar seu próprio validador ao fazer sua solicitação. Se o servidor responder
com 304 (não modificado), o cache pode retornar sua cópia agora validada para o cliente 
com uma resposta 200 (OK). Se o servidor responder com uma nova entidade e validador de cache,
no entanto, o cache intermediário pode comparar o validador retornado com o fornecido em 
solicitação do cliente, usando a forte função de comparação. Se o validador do cliente for
igual ao servidor de origem, o cache intermediário simplesmente retorna 304 (Não 
Modificado). Caso contrário, ele retornará a nova entidade com uma resposta 200 (OK).

    Se uma solicitação incluir a diretiva sem cache, NÃO DEVE incluir min-fresh, 
max-obsoleto ou max-age. 

cortesia: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

Não aceite isso como resposta - vou ter que lê-lo para entender o verdadeiro uso dele :)

Não sou especialista em cache, mas Mark Nottingham é. Aqui estão os documentos de cache dele . Ele também tem excelentes links na seção Referências.

Com base na minha leitura desses documentos, parece que max-age=0poderia permitir que o cache enviasse uma resposta em cache a solicitações que chegavam no "mesmo tempo" em que "mesmo tempo" significa que, juntas o suficiente, parecem simultâneas ao cache, mas no-cachenão .

A propósito, vale a pena notar que alguns dispositivos móveis, particularmente produtos da Apple como iPhone / iPad, ignoram completamente cabeçalhos como no-cache, no-store, Expira em: 0 ou qualquer outra coisa que você possa tentar forçá-los a não reutilizar o prazo de validade páginas de formulário.

Isso não causou dores de cabeça ao tentarmos dizer o problema do iPad de um usuário, ficar adormecido em uma página que ele alcançou através de um processo de formulário, por exemplo, etapa 2 de 3 e, em seguida, o dispositivo ignora totalmente a loja / diretivas de cache, e até onde eu sei, simplesmente tira o que é um instantâneo virtual da página de seu último estado, ou seja, ignorando o que foi dito explicitamente e, não apenas isso, obtendo uma página que não deve ser armazenada e armazená-lo sem realmente checá-lo novamente, o que leva a todos os tipos de problemas de sessão estranhos, entre outras coisas.

Estou apenas adicionando isso no caso de alguém aparecer e não conseguir descobrir por que eles estão recebendo erros de sessão, principalmente com iphones e ipads, que parecem de longe os piores criminosos nessa área.

Eu fiz testes de depurador bastante extensos com esse problema e esta é minha conclusão: os dispositivos ignoram essas diretivas completamente.

Mesmo em uso regular, descobri que alguns celulares também falham totalmente em procurar novas versões, digamos, Expira em: 0 e depois checam as datas da última modificação para determinar se deve obter uma nova.

Isso simplesmente não acontece, então o que eu fui forçado a fazer foi adicionar strings de consulta aos arquivos css / js nos quais eu precisava forçar atualizações, o que faz com que os dispositivos móveis estúpidos pensem que é um arquivo que não possui, como: .css? v = 1 e v = 2 para uma atualização css / js. Isso funciona em grande parte.

Os navegadores de usuários também, a propósito, se deixados com os padrões, a partir de 2016, como descubro continuamente (fazemos muitas alterações e atualizações em nosso site) também não conseguem verificar as datas da última modificação desses arquivos, mas a consulta O método string corrige esse problema. Isso é algo que eu notei com clientes e pessoas do escritório que tendem a usar padrões normais básicos de usuário em seus navegadores e não têm conhecimento de problemas de cache com css / js etc. o que significa que os padrões para seus navegadores, principalmente o MSIE / Firefox, não estão fazendo o que lhes é pedido, ignoram as alterações e ignoram as datas da última modificação e não são validados, mesmo com Expires: 0 definido explicitamente.

Esse foi um bom tópico com muitas informações técnicas boas, mas também é importante observar o quão ruim é o suporte para esse material em dispositivos móveis. A cada poucos meses, tenho que adicionar mais camadas de proteção contra sua falha para seguir os comandos do cabeçalho que eles recebem ou para interceptar adequadamente esses comandos.

Uma coisa que (surpreendentemente) não foi mencionada é que uma solicitação pode indicar explicitamente que aceitará dados obsoletos, usando a max-stalediretiva. Nesse caso, se o servidor respondeu max-age=0, o cache consideraria a resposta obsoleta e estaria livre para usá-la para satisfazer a solicitação do cliente [que solicitou dados potencialmente obsoletos]. Por outro lado, se o servidor envia no-cacheisso realmente supera qualquer solicitação do cliente (com max-stale) por dados antigos, como o cache DEVE revalidar.

A diferença é que nenhum cache (sem armazenamento no Firefox) impede qualquer tipo de cache. Isso pode ser útil para impedir que páginas com conteúdo seguro sejam gravadas em disco e para páginas que sempre devem ser atualizadas, mesmo que sejam visitadas novamente com o botão Voltar.

max-age = 0 indica que uma entrada de cache é obsoleta e requer nova validação, mas não impede o armazenamento em cache. Geralmente, os navegadores validam os recursos apenas uma vez por sessão do navegador, portanto, o conteúdo pode não ser atualizado até que o site seja visitado em uma nova sessão.

Geralmente, os navegadores não excluem entradas de cache expiradas, a menos que estejam recuperando espaço para conteúdo mais recente quando o cache do navegador estiver cheio. Usando no-store, no-cache permite que uma entrada de cache seja excluída explicitamente.