Полная перезагрузка страницы в Post / Redirect / Get игнорирует управление кэшем - PullRequest
11 голосов
/ 09 июня 2010

У меня есть страница, которая загружает много изображений, CSS и JavaScript.Я добавил заголовок Expires далекого будущего и установил для Cache-Control значение public для этих внешних зависимостей, чтобы их можно было кэшировать.Но каждый раз, когда я делаю Post / Redirect / Get Chrome, пытается загрузить их снова.Это поведение очень похоже на перезагрузку страницы.Я добавил ETag и обработал заголовок If-None-Match, который немного помогает, но он по-прежнему генерирует слишком много бесполезных запросов.

Как мне указать chrome и safari, чтобы они получали файлы из кэша?

chrome   NOK
safari   NOK
firefox  OK
ie       OK

Также см. Полная перезагрузка страницы в Post / Redirect / Получить игнорирующий элемент управления кэшем на форуме поддержки Google.

Уточнение:

Я не хочу, чтобы браузер дважды запрашивал image1.png.Это должно быть кэшировано.

200 GET  page1.html
200 GET  image1.png (Cache-Control: public, Expires and ETag)
302 POST action.asp (form submitted from page1.html, redirects)
200 GET  page2.html
304 GET  image1.png (If-None-Match)

Пример:

Я создал простой пример для иллюстрации проблемы.

http://crydust.be/lab/prg/

Заголовки:

Заголовки, которые я отправляю с изображением:

HTTP/1.1 200 OK
Date: Fri, 18 Jun 2010 11:30:22 GMT
Server: Apache
Cache-Control: public, max-age=86400
Expires: Sat, 19 Jun 2010 11:30:24 GMT
Etag: "123"
Content-Length: 866
Content-Type: image/png

Что должно сделать его кэшированным в течение 24 часов.Нет Vary: * или чего-либо подобного.

Обновление: Это поведение теперь также присутствует в Safari Mobile на iOS 4. Огромный регресс в скорости загрузки страницы.

Обновление: Существует сообщение об ошибке в веб-наборе bugzilla. Ошибка 38690 - отправка POST, которая приводит к перенаправлению сервера, приводит к повторной загрузке всех кэшированных элементов

Обновление: Проблема сохраняется на iOS 4.0.1

Обновление: Проблема сохраняется на iOS 4.1

Обновление: Проблема сохраняется на iOS 4.2

Обновление: Проблема сохраняется на iOS 4.2.1 и в Chrome с версии 6 до 9.

Обновление: В проекте Chromium есть сообщение об ошибке.(вы можете пометить его, чтобы показать свою осторожность) Проблема 68621: публикация / перенаправление / получение игнорирующих инструкций кэша

Обновление: Проблема сохраняется в Chrome с версии 6 до10. Это ошибка 9 месяцев.

Обновление: Проблема исправлена ​​с 2011-03-21 19:33:07 PST.Это отражается на поведении хрома 12 (канарейка).

Ответы [ 3 ]

1 голос
/ 09 июня 2010

Когда вы выполняете F5 / обновление в Chrome, Safari или IE8, все ресурсы GET запрашиваются снова, даже если они были кэшированы.

Если вы смотрите запрос / ответ с помощью инструментов dev или Fiddler, выВы увидите, что сервер отвечает со статусом HTTP 304 и без содержимого.Это говорит браузеру, что им не нужно загружать его снова и что они могут продолжать использовать кеш.

В файлах вкладок ресурсов Chrome dev tools, обновленных таким образом, будет время ожидания, но загрузкавремя 0 мс.

Если вы перезагрузите страницу, выйдя и вернувшись, вы обнаружите, что эти кэшированные файлы не извлекаются снова и сервер не проверяется.

Такое поведение F5 / refreshдля GET статический ресурс правильный - это FX и IE6, которые делают это неправильно.Это также помогает с запутанной командой CTRL + F5, о которой большинство пользователей не знают.

Вы не можете кэшировать POST или страницы, которые возвращают временное перенаправление HTTP:

POST изменяет данные идолжен всегда запрашивать перед отправкой снова, и его результаты никогда не кэшируются.

Перенаправления обрабатываются на низком уровне в HTTP-компоненте - ниже кэширования.На самом деле, он говорит браузеру, что нужно получить ресурс откуда-то еще, и хотя он может кешировать, он не кешировал редирект и должен проверить снова.

Вы должны иметь возможность кэшировать постоянное перенаправление 301, но не следует кэшировать временные перенаправления 302 или 303 в соответствии со спецификацией HTTP .

0 голосов
/ 22 июля 2015

Исправление: cache-control: no-store

(Вы также можете использовать код состояния 307 вместо 302, что сохранит метод.)

Решение найдено- после многих дней разочарования - в комментарии к об этой открытой ошибке WebKit :

CachedRawResource теперь сохраняет цепочку перенаправления и имеет некоторую тривиальную логику для проверки правильности, но ее нетпочти завершен (проверяет только cacheControlContainsNoStore ()).И, конечно, другие типы ресурсов не имеют ничего.

0 голосов
/ 23 октября 2010

F5 перезагружает все ресурсы страницы в некоторых браузерах, поэтому они игнорируют заголовки кэша и снова запрашивают каждый ресурс.

Если вы хотите «кэшировать» POST-страницы, вам необходимо преобразовать эти страницы в статические ресурсы, то есть, например, создать файл .html из .php, а затем использовать его как статический ресурс.

Это действительно ТОЛЬКО в том случае, если содержимое страницы не меняется

...