Suportando js / css / downgrades de imagem com o servidor nginx

Question

Eu tenho um requisito em que preciso dar suporte ao downgrade do código do meu servidor.

Eu tenho a seguinte linha no meu arquivo de configuração nginx, indicando que o navegador pode armazenar a página em cache, mas precisa validar com o servidor para verificar se o arquivo foi alterado.

add_header Cache-Control "no-cache";

Esta configuração funciona perfeitamente para mim com todas as atualizações feitas no código do meu servidor.

Mas quando se trata de fazer o downgrade de um recurso para uma versão mais antiga, quando o navegador tenta validar a alteração do recurso, o nginx diz que o recurso não mudou, então o navegador mostra o recurso em cache (mais recente) em vez do rebaixado recurso (mais antigo).

Como solução alternativa, eu poderia usar a seguinte configuração para desabilitar o cache completamente, mas não é eficiente, e eu gostaria de ter o cache.

add_header Cache-Control "no-store";

Então, como eu faria o nginx reconhecer downgrades ??

    

Answer 1

Em um cenário sem cache, o navegador normalmente emitirá um cabeçalho If-Modified-Since com uma solicitação GET, para ver se o arquivo em questão foi alterado da cópia em cache.

O servidor irá:

1. return a 304 - Resposta não modificada
2. retorna outro código:
   • 200 - OK se a data de modificação no servidor for posterior à passada com o cabeçalho
   • Outro - qualquer outro código que possa ser retornado (4xx, 5xx, etc)

O Nginx usará o registro de data e hora modificado no arquivo que está sendo utilizado para gerar o cabeçalho Última modificação e para comparação com If-Modified-Since.

Devido a isso, a atualização do registro de data e hora de um arquivo com touch /path/to/myfile.ext fará com que o nginx identifique-o como modificado após a data If-Modified-Since e permitirá que o nginx exiba o arquivo.

Alternativamente, você deve ser capaz de forçar uma nova busca especificando explicitamente um cabeçalho 'Last Modified' em sua configuração nginx após a data prevista de If-Modified-Since. Em seu cenário, isso implicaria essencialmente:

1. Faça o downgrade do seu código
2. Modifique a configuração do nginx com a data atual (por exemplo): add_header Last-Modified Mon, 09 Jan 2012 17:07:00 GMT
3. Recarregar nginx

Um ponto importante de menção é que se seus ativos estáticos mudarem depois disso, o cabeçalho codificado não refletirá a mudança (por exemplo, mesmo quando você 'atualizar' seu código, você ainda terá que alterar manualmente a configuração.

    

Answer 2

Primeiro de tudo, "no-cache" não significa necessariamente o que você acha que significa na prática. Eu suspeito que você realmente quer usar "Cache-Control: max-age = 0, must-revalidate". Alguns navegadores (Firefox) tratam incorretamente "no-cache" como um equivalente de "no-store", e não fazem cache de nada no disco. Eles simplesmente recuperam todo o conteúdo da fonte em cada carregamento de página, o que é um terrível desperdício de largura de banda e é uma droga para a experiência do usuário.

Em segundo lugar, seu caso de uso específico é exatamente o que ETags foi criado, em vez da simples data apenas para encaminhamento lógica que é usada sem eles. (Todo o site vinculado é ótimo ler sobre cache, não apenas em e-tags).

Finalmente, você deve considerar nomear seus recursos com alguma forma de identificador de data (ou melhor ainda, hash de conteúdo) para que você nunca precise se preocupar com esse tipo de coisa. Você pode então definir o controle de cache para 1 ano. Isso requer alterações de fluxo de trabalho e scripts de criação, embora para muitos sites renomeiem arquivos e substituam links. Mas é isso que o Google e os outros grandes garotos fazem ...