Cabeçalhos de controle de cache com o IIS 7.5

Question

Estou tentando entender o cache do cliente (navegador da Web) e como ele funciona em relação aos cabeçalhos de controle de cache do IIS 7.5.

Em particular:

1. Se quisermos forçar os clientes a recarregar recursos em cache, como o IIS deve ser configurado?

2. Precisamos definir o conteúdo da web para expirar imediatamente se os recursos no servidor tiverem uma Data de modificação mais recente (ou valor de ETag)?

3. No momento, não estamos definindo nenhum cabeçalho de cache. Portanto, se eu definir um cabeçalho de cache de no-cache (que, na minha opinião, equivale a expirar o conteúdo da Web imediatamente), isso forçará o navegador da Web a obter uma nova versão de um determinado arquivo. Ou o navegador só solicitará uma nova versão depois de considerar que sua cópia atual está obsoleta e, desse ponto em diante, não a armazenará em cache?

Seria uma boa prática definir um sinalizador de controle de cache de 1 semana e, em seguida, 8 dias antes de eu saber que vou fazer uma alteração definir o controle de cache como, por exemplo, 30 minutos?

Mas se eu fizer isso e precisar expirar imediatamente um item dos caches de usuários, porque houve um problema com isso, como faço isso?

    

Answer 1

Uma maneira de entender o cache do agente cliente / usuário é visualizar o navegador como implementando um cache intermediário para si mesmo (o que, na verdade, é feito por Cache-Control: private ). Isso abstrai toda a terminologia para padrões simples de solicitação e resposta e, na maioria dos casos, o cache do navegador se comporta da mesma maneira que um proxy ou um cache intermediário. Manter isso em mente é útil ao ler a documentação oficial sobre o assunto no IETF RFC 2616: link .

1. Defina o cabeçalho "Expires" como "Immediately" (que envia Cache-Control: no-cache ) conforme descrito em link e link .

2. Não. Se você não enviar nenhum cabeçalho de Cache-Control, o IIS deverá enviar a versão mais recente do recurso e um cliente deverá reconhecê-lo a partir do cabeçalho Last-Modified ou do ETag.

3. Sua primeira declaração está correta: o envio de no-cache instruirá o cliente a solicitar o recurso toda vez, mesmo que já tenha armazenado em cache. Alguns clientes se comportam mal e armazenam esses recursos de qualquer maneira, mas você também pode usar must-revalidate para garantir que obtenha uma nova cópia

Quanto às práticas recomendadas, quanto tempo você armazena em cache depende do aplicativo e das necessidades dos usuários. Você sempre pode enviar Cache-Control: must-revalidate para resolver os problemas mencionados, portanto, não há necessidade de alterar globalmente a expiração do seu cache.