Apache mod_expires

Question

Estou bastante confuso com todo o acesso e modificação.

Eu quero que os arquivos sejam armazenados em cache até serem modificados. Se os dados forem os mesmos, mostre a versão do cache. Se os dados foram alterados, baixe a versão atualizada e armazene-a em cache.

Eu não vejo por que você quer algo diferente? Todo esse acesso mais 6 meses não faz sentido para mim. Solicite um novo arquivo se a data da última modificação for mais recente que a data do cache. Isso não pode ser feito de maneira tão simples?

Eu quero poder criar index.html em 1/1/2012 e fazer com que todos o armazenem em cache. Eu não quero que seja baixado novamente até que eu edite. Digamos que eu edite em 1/5/2012 e alguém que não tenha visto index.html desde 1/1/2012 venha, eles devem ver que eles têm 1/1/2012 cache, mas agora o arquivo tem um último mod tempo de 05/01/2012, eles fazem o download da versão 1/5/2012 e armazenam em cache.

Eu nunca quero editar algo e fazer com que um usuário não o veja por nenhum período de tempo. Quero que todas as minhas edições sejam visualizadas na próxima solicitação.

Como posso fazer isso para todos os arquivos?

    

Answer 1

Não faça nada. O Apache já tem o comportamento que você espera da caixa.

Quando um navegador faz uma solicitação para um URL já visto e armazenado em cache, e o usuário não está forçando explicitamente um recarregamento, ele inclui um If-Modified-Since header com o registro de data e hora da solicitação anterior. Se o servidor determinar que o ativo não foi alterado desde o timestamp If-Modified-Since , ele responde apenas com 304 Not Modified . (Além dos timestamps, há outro cabeçalho chamado ETag usado para verificar a validade do cache que funciona comparando os hashes do conteúdo, mas isso não adiciona nada a essa discussão.)

A única vez que você deseja usar qualquer um dos recursos mod_expires é quando você quer dizer ao navegador para não se incomodar em fazer uma solicitação HTTP para verificar se um ativo em cache está atualizado por algum período de tempo. Por exemplo, você poderia ter um esquema em que seu arquivo CSS está localizado em /style.1.css e nomear versões subseqüentes dele como /style.2.css , /style.3.css , etc. Nesse caso, você poderia salvar a sobrecarga de uma solicitação HTTP ao todo, definindo um cabeçalho Expires .

    

Answer 2

Existem dois conceitos aqui: armazenamento em cache e economia de largura de banda. Para o seu caso de uso, eu esqueci de Expires: , mas explicarei depois.

Se você veicular um arquivo físico de uma pasta, o servidor da Web adicionará um ou dois cabeçalhos:

• ETag: xyzzas4324@asdad/33 : que funciona como um ID para essa versão do arquivo e muda se o conteúdo do arquivo for alterado; e / ou
• Last-Modified: <date> : que é a mesma data de modificação, conforme visto nas propriedades do arquivo.

Então, na próxima vez, o navegador solicitará http: // $ URL / file com uma pequena alteração:

• %código%; e / ou
• If-None-Match: xyzzas4324@asdad/33

Se o arquivo não foi alterado, o servidor envia de volta um If-Modified-Since: <same date> que indica ao navegador que ele deve exibir a versão em cache.

Aviso: isso evitou apenas a transferência repetida desse arquivo em particular; o navegador ainda tinha que esperar por uma resposta do servidor web. Então ainda há alguma latência.

Que é onde 304 Not Modified entra. Imagine que o arquivo solicitado é um feed RSS. Se houver um Expires header, a solicitação not será repetida por esse navegador durante esse intervalo, período. Nenhuma latência do navegador aguardando o servidor, sem aumento de carga.

Há um livro que entra em mais detalhes: Construindo sites escaláveis. Ele entra em mais detalhes sobre esses truques, mas darei o rápido resumo:

É assim que você deve mudar do logotipo antigo para o novo, assumindo que você tenha definido Expires: <2 hours from now> no total de Expires: <6 years>

assets/* v1:

<h1>Welcome to Example Inc!</h1>
<img src="assets/logo_v1.jpg">

index.html v2:

<h1>Welcome to Example Inc!</h1>
<img src="assets/logo_v2.jpg">

Observe que index.html não tem index.html . Obtém o tratamento Expires: <6 years> . Quando você altera um dos ativos, aumenta o número da versão e altera os arquivos .html usados.

E você obtém o melhor dos dois mundos.

    

Answer 3

O que você descreve como desejado é o modo como qualquer servidor da web moderno trabalha por padrão.

Se você não enviar cache explícito / expirar cabeçalhos (ou se você enviar cabeçalhos etag) toda vez que um usuário solicitar uma página / ativo (asset = js, css, imagens etc), o navegador enviará uma solicitação ao seu servidor. A partir de sua descrição, esse é o comportamento desejado - você deseja que o navegador sempre solicite a página / recurso e receba o conteúdo atualizado ou uma resposta 304 Not Modified empty indicando que o que o usuário armazenou anteriormente em cache é a versão mais recente.

Portanto, o que você quer fazer é remover os cabeçalhos que você adicionou para que o apache baseie sua resposta no (apenas) cabeçalho da última modificação.

Por que você deseja um comportamento diferente:

O acima é apropriado para páginas html - mas é ineficiente para tipos de conteúdo que raramente mudam ou onde você pode simplesmente mudar o URL quando o conteúdo muda. Enviar uma solicitação ao seu servidor e receber uma resposta 304 Not Modified não é gratuita - leva tempo (dependendo de quantos recursos estão na página - isso pode levar muito tempo) e gera carga no servidor (sim, manipulação Muitas solicitações de ativos estáticos podem afetar significativamente o desempenho de um servidor), por isso é ruim para o usuário e é ruim para você. É por isso que você gostaria de adicionar cabeçalhos de expiração longa e usar cache-busting sempre que possível reduzir ao mínimo as solicitações http, forçando os usuários a baixar novamente os ativos quando eles mudarem.

Existe um excelente guia de htaccess disponível em o projeto html5boilerplate . Ele detalha como otimizar cabeçalhos (cache) para melhorar o desempenho e a experiência do usuário. Você não precisa ficar preso nos detalhes: basta soltar o padrão .htaccess sua raiz do documento e verifique se você está esperando. A configuração padrão deve fazer exatamente o que você deseja com o benefício adicional de adicionar cabeçalhos de cache de práticas recomendadas para ativos estáticos. Se a sua questão não era de fato sobre conteúdo em HTML, mas outro tipo de conteúdo - leia as referências antes de simplesmente desabilitar todo o bom trabalho que a lógica do cache no arquivo .htaccess faz para você;)