Do RFC 2616
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
sem 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. 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.
Por isso, direciona os agentes a revalidar todas as respostas.
Comparou isso com
deve revalidar
Quando a diretiva must-revalidate está presente em uma resposta recebida por um cache, esse cache NÃO DEVE usar a entrada depois que se tornar obsoleto para responder a uma solicitação subsequente sem primeiro revalidá-lo com o servidor de origem
Por isso, direciona os agentes a revalidar respostas obsoletas .
Particularmente no-cache, é assim que os agentes de usuários tratam empiricamente essa diretiva?
Qual é o sentido de no-cachese existe must-revalidatee max-age?
Veja este comentário:
http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/
sem cache
Embora essa diretiva pareça instruir o navegador a não armazenar em cache a página, há uma diferença sutil. A diretiva “sem cache”, de acordo com a RFC, informa ao navegador que deve revalidar com o servidor antes de servir a página a partir do cache. A revalidação é uma técnica interessante que permite que o aplicativo economize a largura de banda. Se a página que o navegador armazenou em cache não mudou, o servidor apenas sinaliza isso para o navegador e a página é exibida no cache. Portanto, o navegador (pelo menos em teoria) armazena a página em seu cache, mas a exibe somente após a revalidação com o servidor. 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.
Alguém tem algo mais oficial sobre isso?
Atualizar
A diretiva de revalidação obrigatória deve ser usada pelos servidores se e somente se a falha na validação de uma solicitação na representação puder resultar em operação incorreta, como uma transação financeira silenciosamente não executada.
Isso é algo que nunca levei a sério até agora. O RFC está dizendo para não usar levemente revalidar levemente. O problema é que, com os serviços da Web, você precisa ter uma visão negativa e assumir o pior para seus aplicativos clientes desconhecidos. Qualquer recurso obsoleto pode causar um problema.
E outra coisa que eu considerei, sem Last-Modified ou ETags, o navegador só pode buscar todo o recurso novamente. No entanto, com ETags, observei que o Chrome pelo menos parece revalidar a cada solicitação. O que torna essas diretivas discutíveis ou, pelo menos, mal nomeadas, pois não podem revalidar adequadamente, a menos que a solicitação também inclua outros cabeçalhos que causam 'sempre revalidar' de qualquer maneira.
Eu só quero deixar esse último ponto mais claro. Ao definir, must-revalidatemas não incluir, ETag ou Last-Modified, o agente só pode obter o conteúdo novamente, pois não há nada a ser enviado ao servidor para comparação.
No entanto, meus testes empíricos mostraram que, quando ETag ou dados de cabeçalho modificados são incluídos nas respostas, os agentes sempre revalidam de qualquer maneira, independentemente da presença do must-revalidatecabeçalho.
Assim, o ponto de must-revalidateé forçar um 'esconderijo de bypass' quando ele vai obsoleto, o que só pode acontecer quando tiver definido um tempo de vida / idade, assim, se must-revalidateestiver definido em uma resposta sem idade ou outros cabeçalhos, ele efetivamente se torna equivalente a no-cacheuma vez a resposta será considerada imediatamente obsoleta.
- Então, finalmente vou marcar a resposta de Gili!