Идеальные заголовки управления кешем HTTP для разных типов ресурсов

82

Я хочу найти минимальный набор заголовков, который работает "со всеми" кешами и браузерами (также при использовании HTTPS !)

На моем веб-сайте у меня будет три вида ресурсов:

(1) Кэшируемый навсегда (общедоступный / равный для всех пользователей)

Пример: 0A470E87CC58EE133616F402B5DDFE1C.cache.html ( автоматически создается GWT )

  • Этим файлам автоматически присваивается новое имя при изменении содержимого (на основе MD5).

  • Они должны как можно больше кэшироваться, даже при использовании HTTPS (так что, я полагаю, я должен установить Cache-Control: public, особенно для Firefox?)

  • Они не должны требовать, чтобы клиент совершал обход к серверу и обратно, чтобы проверить, изменилось ли содержимое.

(2) Время от времени меняется (общедоступно / одинаково для всех пользователей)

Примеры: index.html, mymodule.nocache.js.

  • Эти файлы изменяют свое содержимое без изменения URL-адреса при развертывании новой версии сайта.

  • Их можно кэшировать, но, вероятно, потребуется повторная проверка каждый раз.

(3) Индивидуально для каждого запроса (частный / индивидуальный)

Пример: ответы в формате JSON

  • Эти ресурсы ни в коем случае нельзя кэшировать на диск в незашифрованном виде. (За исключением, может быть, у меня есть несколько конкретных запросов, которые можно было бы кэшировать.)

У меня есть общее представление о том, какие заголовки я, вероятно, использовал бы для каждого типа, но всегда есть что-то, чего мне может не хватать.

http  caching  https  http-headers 
— Крис Леркер
источник
Спасибо за ваши ответы, комментарии и ссылки. Я еще немного экспериментирую, но думаю, смогу найти решение!
— Крис Леркер,
2
Достижение №3 обычно невозможно.
— EricLaw
— Микко Ранталайнен

Ответы:

91

Я бы, наверное, использовал следующие настройки:

  1. Cache-Control: max-age=31556926- Представления могут кэшироваться любым кешем. Кэшированное представление считается свежим в течение 1 года:

    Чтобы отметить ответ , как «никогда не истекает,» сервер происхождения посылает Истекает срок примерно один год с момента , когда ответ отправляется. Серверы HTTP / 1.1 НЕ ДОЛЖНЫ отправлять даты истечения срока действия более чем на один год в будущем.

  2. Cache-Control: no-cache- Представления могут кэшироваться любым кешем. Но кеши должны отправить запрос на исходный сервер для проверки перед выпуском кэшированной копии.
  3. Cache-Control: no-store - Кеши не должны кэшировать представление ни при каких условиях.

См . Учебное пособие Марка Ноттингема по кэшированию для получения дополнительной информации.

— Гамбо
источник
1
@Gumbo: Я почти уверен в том, что мне нужно сделать общедоступным , когда я хочу, чтобы Firefox 3+ кэшировал общедоступные файлы на диск при использовании HTTPS: stackoverflow.com/questions/174348/…
— Крис Леркер,
2
Некоторые браузеры, такие как IE, начинают обрабатывать Cache-Control: no-cache, как если бы это был no-store. По общему признанию, это не согласно RFC, но это сделано сознательно, чтобы «исправить» ошибку, допущенную МНОГИМ использованием без кеша, чтобы предотвратить хранение конфиденциальных данных в незашифрованном виде на диске.
— AviD 09
1
@chris_l, я попал по этой ссылке: palisade.plynt.com/issues/2008Jul/cache-control-attributes . Я не помню, как себя вели предыдущие версии, хотя думаю, что IE7 тоже.
— AviD
2
Кроме того, Firefox больше не требует PUBLIC в Cache-Control для кэширования ресурсов HTTPS. Но лучше всего просто протестировать свой сайт, наблюдая за трафиком, например, с помощью Fiddler.
— EricLaw
3
Не рекомендуется устанавливать для параметра управления кешем 100 лет. Во-первых, спецификация рекомендует максимум 1 год. Во-вторых, любое значение более 68 лет приводит к немедленному истечению срока действия IE8 и ниже: blogs.msdn.com/b/ieinternals/archive/2010/01/26/…
— EricLaw
-2

Случаи один и два на самом деле представляют собой один и тот же сценарий. Вы должны установить, Cache-Control: publicа затем сгенерировать URL-адрес, включающий номер сборки / версию сайта, чтобы у вас были неизменные ресурсы, которые потенциально могут длиться вечно. Вы также хотите установить Expiresзаголовок на год или более в будущем, чтобы клиенту не нужно было проверять актуальность.

В случае 3 для максимальной гибкости вы можете выполнить все следующие действия: 

"Cache-Control", "no-cache, must-revalidate"
"Expires", 0
"Pragma", "no-cache"
— Эндрю Л
источник
Различные URL-адреса для новых сборок, вероятно, не подходят: а) Это заставит клиента повторно загрузить файлы, кэшируемые навсегда. Чтобы этого избежать, они получают уникальные имена. b) Основной URL-адрес моего сайта должен быть просто https://www.example.com/c) Я хочу, чтобы закладки всегда ссылались на новейшую версию моего сайта (представьте, закладки на вопрос stackoverflow будут содержать номер сборки сайта).
— Крис Леркер,
Привет, Крис! Этот подход обычно используется для ресурсов CSS и JS, а не для документов. Я согласен, что это не применимо для идентификаторов документов, и в этом случае вы должны просто установить cache-control public, Last-Modified и etag в заголовках, которые будут вызывать проверку актуальности каждый раз, и только 304 будет отправлено обратно, если нет изменений с момента последней загрузки. В качестве альтернативы вы можете загрузить фактическое динамическое содержимое страницы на каждой странице через JS, чтобы сохранить URL-адрес, но при этом обеспечить эффективное кеширование.
— Эндрю Л.
Да, именно так, GWT справляется с этим за меня: мой index.html (время от времени меняющийся) включает mymodule.nocache.js (время от времени меняется), который автоматически включает правильные файлы, кэшируемые навсегда (большие части js, управляемые GWT комплекты изображений, ...) Единственное, что мне остается, это установка правильных заголовков http для каждого типа. Я хочу свести эти заголовки к минимуму, поскольку на них приходится большой процент объема передачи. Так что мне нужны, например, и Last-Modified, и ETag и т. Д.?
— Крис Леркер,
«Expires» действительно должно быть датой, а не числом 0. Оно должно иметь то же значение, что и заголовок «Date». См. Mnot.net/cache_docs
— Люк Хатчисон
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.