O cabeçalho HTTP Last-Modified é requerido para o cache do navegador?

5

Quando descubro o cabeçalho Last-Modified no Apache ( ETags também está desabilitado), o Firefox (4.01) não armazenará em cache nenhum arquivo independentemente se eu definir um futuro Expires header ou ative o cabeçalho Cache-Control .

O cabeçalho Last-Modified (e / ou um ETag ) é necessário para o cache do navegador?

De aqui :

If no validator (an ETag or Last-Modified header) is present on a response, and it doesn’t have any explicit freshness information, it will be considered uncacheable.

... bem, se por "Informação de Frescura" eles significam cabeçalho "Cache-Control" ou "Expires", o Firefox deve estar em cache sem o cabeçalho Last-Modified.

EDITAR MAIS INFORMAÇÕES DO FIREFOX

Note que nenhuma tentativa de gerar um 304 em qualquer arquivo PHP servido pelo Apache 2.2 no Firefox 4.01 é bem-sucedida (recarregar, nova visita, etc.) sem um Last-Modified cabeçalho, independentemente de qualquer combinação sendo definida como um cache válido Cache-Control header, o Expires header ou os dois cabeçalhos.

foo.php : o conteúdo deste arquivo simplesmente ecoa "Hello World".

HTTP/1.1 200 OK
Date: Mon, 06 Jun 2011 14:04:58 GMT
Server: Apache
Cache-Control: public, max-age=3600
Expires: Fri, 01 Jul 2011 21:23:55 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 1594
Keep-Alive: timeout=10, max=500
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8

EDIT PARA MAIS MAIS ESTRANHAS FIREFOX 4.01 ACHADOS

Ainda mais estranho, baseado no que eu vi com o Firefox 4.01, nenhuma forma de cabeçalho de controle de cache do lado do servidor (Expires e / ou Cache-Control) influencia o comportamento de cache do Firefox. O Firefox só se preocupa com as informações de atualização (Etag ou Last-Modified).

Em resumo, se o arquivo tiver sido modificado, o Firefox o recarregará, independentemente de quaisquer cabeçalhos de expiração ou de controle de cache. Se o arquivo não contiver nenhuma informação de atualização, o Firefox o recarregará, não importa o que aconteça.

Se alguém descobrir de forma diferente em suas observações, atualize-me.

OUTRA EDIÇÃO

De este link :

13.2.1 Server-Specified Expiration

An expiration time cannot be used to force a user agent to refresh its display or reload a resource; its semantics apply only to caching mechanisms, and such mechanisms need only check a resource's expiration status when a new request for that resource is initiated. See section 13.13 for an explanation of the difference between caches and history mechanisms.

    
por Jeff 06.06.2011 / 01:15

2 respostas

2

Desconfie de ler artigos aleatórios na internet (embora as coisas de Mark Nottingham sejam geralmente sensatas). A fonte definitiva deve sempre pelos RFCs. E de acordo com o RFC 2616 , um navegador deve armazenar em cache um documento com um cabeçalho Expires: onde o timestamp está no futuro, ou onde outras instruções de armazenamento em cache válidas são fornecidas, desde que o documento não seja retornado em resposta a uma solicitação POST.

É perfeitamente válido definir uma duração máxima sem uma última modificação - e a especificação aborda explicitamente isso.

Certamente o que você descreve parece muito incomum e implica que o FF4.01 nunca armazenará conteúdo em cache - eu ficaria surpreso que ele tenha passado nos testes de CQ com uma omissão tão evidente. Você pode fornecer detalhes sobre as solicitações e as respostas que provam isso (por exemplo, com liveheaders )?

    
por 06.06.2011 / 15:01
0

Isso varia de acordo com o navegador, mas geralmente eu trabalho usando a teoria de que, se o conteúdo for armazenado corretamente, ele precisará de pelo menos um cabeçalho Etag & de última modificação, Expires é uma vantagem, mas se tiver um etag, o navegador geralmente priorizará isso acima de qualquer outra coisa.

    
por 06.06.2011 / 01:22