Почему Google Chrome НЕ использует кэшированные страницы, когда я определяю заголовок HTTP "Expires"

Question

Я отправляю корректно отформатированные HTTP-заголовки ответа «Expired» (например, «Ср, 04 мая 2011 г. 09:29:09 GMT») со страницей, обслуживаемой через https://[host]:{port}/ (с [host] является localhost) из приложения J2EE, используя response.setDateHeader("Expires", {milliseconds a few seconds in the future} ).

На моих страницах есть ссылка на ту же страницу.Когда я нажимаю на эту ссылку из Firefox (4) или IE (8), страница перезагружается из кэша до истечения времени истечения.По истечении времени, истекшего, нажатие на ту же ссылку приводит к загрузке страницы с сервера со свежими данными.Если я нажимаю F5 в любом из упомянутых браузеров, страница перезагружается с новыми данными с сервера (Firebug показывает, что Cache-Control: max-age=0 отправляется с запросом).

В Google Chrome, и F5, инажатие на ссылку имеет тот же эффект.Страница ВСЕГДА перезагружается с сервера новыми данными.

Мне не удалось найти какого-либо хорошо документированного объяснения этого эффекта.

Кто-нибудь знает, почему в моем случае Google Chrome не учитывает заголовки «Expired», которые сервер отправляет вместе с ответами на страницы, и, следовательно, ВСЕГДА запрашивает данные с сервера?

Answer 1

Способ работы Chrome в этом отношении может вызвать крайнюю путаницу. Кажется, что нажатие клавиши F5 или «перезагрузить эту страницу» просто не позволяет chrome обслуживать запрос из кэша. Это легко сравнить с нажатием клавиши ввода в окне URL, где он будет использовать кеш, хотя в обоих случаях заголовок запроса (который никуда не отправляется) имеет Cache-Control: max-age = 0.

Если вы нажмете Ctrl + F5, вы получите Cache-Control: no-cache. Я думаю, что разница между F5 и ctrl + F5 заключается в том, что оба приведут к отправке запроса на сервер, но в случае ctrl + F5 сервер должен знать, что он не отвечает с 304 без изменений.