Ідеальні заголовки управління кешем 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
Досягти No3, як правило, неможливо.
— EricLaw
Дивіться також: stackoverflow.com/questions/6491789 / ...
— Мікко Rantalainen

Відповіді:

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 так, ніби він не зберігається. Це, правда, не згідно з RFC, але це свідомо зроблено, щоб "виправити" помилку, зроблену БАГАТОЮ, використовуючи no-cache, щоб запобігти збереженню конфіденційних даних незашифрованими на диску.
— AviD
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-ресурсів, а не для документів. Я погоджуюсь, що це не застосовується для ідентифікаторів документів, і в цьому випадку вам слід просто встановити кеш-контроль public, Last-Modified та etag у заголовках, що буде спричиняти перевірку свіжості кожного разу, і лише 304 буде відправлено назад, якщо змін з моменту останнього завантаження. Крім того, ви можете завантажити фактичний вміст динамічної сторінки на кожній сторінці через JS, щоб зберегти URL-адресу, одночасно дозволяючи ефективне кешування.
— Andrew L
Так, це майже такий спосіб, GWT вирішує це для мене: мій index.html (періодично змінюється) включає mymodule.nocache.js (періодично змінюється), який автоматично включає правильні файли, які можна назавжди кешувати (великі частини js, керовані GWT пакети зображень, ...) Єдине, що мені залишається, це встановлення правильних заголовків http для кожного типу. Я хочу зменшити ці заголовки до мінімуму, оскільки на них припадає великий відсоток обсягу передачі. Тож чи потрібні, наприклад, як «Остання зміна», так і ETag тощо?
— Кріс Лерчер,
"Закінчується" насправді має бути датою, а не числом 0. Він повинен мати таке саме значення, як і заголовок "Дата". Дивіться mnot.net/cache_docs
— Luke Hutchison
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.