Bloqueio de cache via parâmetros

Queremos esconder o busto nas implantações de produção, mas não perder muito tempo tentando descobrir um sistema para isso. Meu pensamento foi aplicar um parâmetro ao final dos arquivos css e js com o número da versão atual:

<link rel="stylesheet" href="base_url.com/file.css?v=1.123"/>

Duas perguntas: isso efetivamente interromperá o cache? O parâmetro fará com que o navegador nunca armazene em cache a resposta desse URL, pois o parâmetro indica que esse é um conteúdo dinâmico?

O parâmetro ?v=1.123indica uma string de consulta e, portanto, o navegador acha que é um novo caminho para, digamos ?v=1.0,. Fazendo com que ele seja carregado do arquivo, não do cache. Como você quiser.

E o navegador assumirá que a fonte permanecerá a mesma na próxima vez que você ligar ?v=1.123e deverá armazená-la em cache com essa sequência. Portanto, ele permanecerá armazenado em cache, no entanto, seu servidor estará configurado, até que você mude para mais ?v=1.124ou menos.

Duas perguntas: isso efetivamente interromperá o cache?

Sim. Até o Stack Overflow usa esse método, embora eu lembre-se de que eles (com milhões de visitantes por dia e zilhões de diferentes versões e configurações de clientes e proxy) tiveram alguns casos extremos onde até isso não foi suficiente para interromper o cache. Mas a suposição geral é que isso funcionará e é um método adequado para interromper o armazenamento em cache nos clientes.

O parâmetro fará com que o navegador nunca coloque em cache a resposta desse URL, pois o parâmetro indica que esse é um conteúdo dinâmico?

Não. O parâmetro não alterará a política de cache; os cabeçalhos de cache enviados pelo servidor ainda se aplicam e, se não enviar, os padrões do navegador.

É mais seguro colocar o número da versão no nome do arquivo real. Isso permite que várias versões existam ao mesmo tempo, para que você possa lançar uma nova versão e, se ainda existirem páginas HTML em cache que solicitem a versão mais antiga, elas obterão a versão que funciona com o HTML.

Observe que, em uma das maiores implantações de versão em qualquer lugar da Internet, o jQuery usa números de versão no nome do arquivo real e permite com segurança coexistir várias versões sem nenhuma lógica especial do lado do servidor (cada versão é apenas um arquivo diferente).

Isso reduz o cache uma vez quando você implanta novas páginas e novos arquivos vinculados (que é o que você deseja) e, a partir daí, essas versões podem ser efetivamente armazenadas em cache (o que você também deseja).

Como já foi dito, o bloqueio de cache com um parâmetro de consulta geralmente é considerado uma má ideia (tm) e existe há muito tempo. É melhor refletir a versão no nome do arquivo. O Boilerplate Html5 recomenda não usar a string de consulta, entre outros.

Dito isto, das recomendações que vi que citaram uma fonte, todas parecem ter sua sabedoria em um artigo de 2008 de Steve Souders. Suas conclusões são baseadas no comportamento dos proxies na época e podem ou não ser relevantes atualmente. Ainda assim, na ausência de informações mais atuais, alterar o nome do arquivo é a opção segura.

Ele travará o cache uma vez, depois que o cliente tiver baixado o recurso, todas as outras respostas serão veiculadas no cache do cliente, a menos que:

1. o parâmetro v é atualizado.
2. o cliente limpa seu cache

Em geral, isso deve ser bom, mas é possível que isso não funcione se houver um cache intermediário (um proxy) configurado para ignorar os parâmetros de solicitação.

Por exemplo, se você estiver fornecendo conteúdo estático através do Akamai CDN, ele poderá ser configurado para ignorar os parâmetros de solicitação para impedir o bloqueio do cache usando esse método.

Depende muito de quão robusto você deseja que seu cache seja. Por exemplo, o servidor proxy squid (e possivelmente outros) assume como padrão não armazenar em cache URLs veiculadas com uma string de consulta - pelo menos quando o artigo foi escrito. Se você não se importa com certos casos de uso que causam falhas desnecessárias no cache, vá em frente com parâmetros de consulta. Mas é muito fácil configurar um esquema de bloqueio de cache baseado em nome de arquivo que evita esse problema.

Encontrei uma comparação das 2 técnicas (string de consulta vs nome do arquivo) aqui :

A versão como uma querystring tem dois problemas.

Primeiro, nem sempre é um navegador que implementa o cache pelo qual precisamos invadir. Diz-se que certos proxies (possivelmente mais antigos) ignoram a sequência de consultas com relação ao seu comportamento em cache.

Segundo, em certos cenários de implantação mais complexos, nos quais você tem vários servidores front-end e / ou vários servidores back-end, uma atualização é tudo instantânea. Você precisa poder fornecer a versão antiga e a nova de seus ativos ao mesmo tempo. Veja, por exemplo, como isso afeta você ao usar o Google App Engine.

Outra abordagem semelhante é usar o htaccess mod_rewrite para ignorar parte do caminho ao servir os arquivos. Sua página de índice nunca armazenada em cache faz referência ao caminho mais recente para os arquivos.

Do ponto de vista do desenvolvimento, é tão fácil quanto usar parâmetros para o número da versão, mas é tão robusto quanto a abordagem do nome do arquivo.

Use a parte ignorada do caminho para o número da versão e o servidor apenas o ignora e serve o arquivo não armazenado em cache.

1.2.3/css/styles.cssserve o mesmo arquivo css/styles.cssdesde que o primeiro diretório é removido e ignorado pelo arquivo htaccess

Incluindo arquivos com versão

<?php
  $version = "1.2.3";
?>

<html>
  <head>
    <meta http-equiv="cache-control" content="max-age=0" />
    <meta http-equiv="cache-control" content="no-cache" />
    <meta http-equiv="expires" content="0" />
    <meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT" />
    <meta http-equiv="pragma" content="no-cache" />
    <link rel="stylesheet" type="text/css" href="<?php echo $version ?>/css/styles.css">
  </head>
  <body>
    <script src="<?php echo $version ?>/js/main.js"></script>
  </body>
</html>

Observe que essa abordagem significa que você precisa desativar o cache da sua página de índice - Usando as tags <meta> para desativar o cache em todos os navegadores?

arquivo .htaccess

RewriteEngine On

# if you're requesting a file that exists, do nothing
RewriteCond %{REQUEST_FILENAME} !-f 
# likewise if a directory that exists, do nothing
RewriteCond %{REQUEST_FILENAME} !-d 

# otherwise, rewrite foo/bar/baz to bar/baz - ignore the first directory
RewriteRule ^[^/]+/(.+)$ $1 [L] 

Você pode adotar a mesma abordagem em qualquer plataforma de servidor que permita a reescrita de URL

(condição de reescrita adaptada do mod_rewrite - reescreva o diretório para a string de consulta, exceto / #! / )

... e se você precisar interromper o cache do ponto de entrada da página de índice / site, sempre poderá usar o JavaSript para atualizá-lo.

<script type="text/javascript">
// front end cache bust

var cacheBust = ['js/StrUtil.js', 'js/protos.common.js', 'js/conf.js', 'bootstrap_ECP/js/init.js'];   
for (i=0; i < cacheBust.length; i++){
     var el = document.createElement('script');
     el.src = cacheBust[i]+"?v=" + Math.random();
     document.getElementsByTagName('head')[0].appendChild(el);
}
</script> 

 <script>
    var storedSrcElements = [
         "js/exampleFile.js",
         "js/sampleFile.js",
         "css/style.css"
          ];

    var head= document.getElementsByTagName('head')[0];
    var script;
    var link;
    var versionNumberNew = 4.6;

    for(i=0;i<storedSrcElements.length;i++){
     script= document.createElement('script');
     script.type= 'text/javascript';
     script.src= storedSrcElements[i] + "?" + versionNumberNew;
     head.appendChild(script);
    }     


     </script> 


       ### Change the version number  (versionNumberNew) when you want the new files to be loaded  ###

Espero que isso ajude você a injetar um arquivo JS externo

<script type="text/javascript"> 
var cachebuster = Math.round(new Date().getTime() / 1000); 
document.write('<scr'+'ipt type="text/javascript" src="external.js?cb=' +cachebuster+'"></scr' + 'ipt>');
</script>

Fonte - Código Cachebuster em JavaScript