Что это must revalidate
Гид по заголовкам кэширования HTTP для начинающих
В статье данные сведения по заголовкам кэширования (ЗК) для HTTP и соответствующее поведение сетей доставки контента (CDN). Если вам хочется разобраться, каким образом заголовки кэширования вписываются в современный веб, или вам просто интересно, о чём говорят ваши коллеги – эта статья для вас.
Если вы уже понимаете преимущества ЗК, и хотите расширить свои знания, я рекомендую вам обратиться к документации от W3.
Что могут ЗК сделать для вас?
Проще говоря, кэширование позволяет хранить веб-ресурсы на удалённых точках по пути от вашего сервера к пользовательскому браузеру. Браузер тоже хранит у себя кэш, чтобы клиенты не запрашивали у вас постоянно одни и те же ресурсы.
Настройки кэширования веб-трафика крайне важны для посещаемых сайтов. Если вы платите за трафик, получаете доход от электронной коммерции, или просто хотите поддерживать свою репутацию хорошего веб-разработчика, вам нужно разбираться в том, как работает кэширование.
В случае ресурсов вроде логотипа вашей компании, favicon сайта или основных CSS-файлов, которые не меняются от запроса к запросу, можно разрешить запрашивающему хранить копии этих файлов какое-то время. Если бы ваши посетители были детьми на заднем сиденье автомобиля, которые бы всё время спрашивали вас «Мы уже приехали?», то это разрешение было бы сродни ответу «Нет, и нам ехать ещё 20 минут, так что запомните мой ответ».
Уменьшая количество запросов к серверу, вы увеличиваете число запросов, которые он может обработать. Картинки, скрипты и таблицы стилей обычно можно кэшировать в хвост и гриву, а динамически создаваемые страницы (форумы, веб-приложения) обычно не стоит. Если вы беспокоитесь в первую очередь за производительность, весь ваш динамический контент должен быть сведён к минимуму ресурсов AJAX, а остальные ресурсы должны кэшироваться по-максимуму.
Для клиентов и CDN
Исторически настройки кэша относились лишь к браузеру клиента, поэтому не стоит забывать и о них. Но сегодня в связи с распространением сетей доставки контента, CDN, важнее понять, как кэширование работает на промежуточных точках веб-сети.
Чтобы не читать всю статью в Википедии: это сервера (во множественном числе), сидящие между вашим сервером и вашим клиентом. Каждый из них кэширует ваш контент в соответствии с правилами, которые вы указываете в различных HTTP-заголовках.
При правильной настройке, CDN передаёт ваш контент клиентам через самый быстрый и ближайший к нему сервер. Кроме этого, CDN работает буфером между вами и пользователями. Нас интересует процент количества кэшированных запросов – тех запросов, которые CDN обработало, не дёргая наш сервер. В зависимости от трафика и архитектуры этот номер может достигать и 90%, хотя эффект вы заметите и при меньших цифрах. Надо заметить, что при небольшом количестве запросов большая их часть будет отправляться на ваш сервер – поэтому этот процент имеет смысл только вместе с временем кэширования и общей нагрузкой сайта. Но если вы настроите один лишь кэш, а заголовки кэширования будут работать неправильно, итоговые показатели могут даже стать хуже, чем были.
Ваши сервера поставляют контент промежуточным серверам, которые присутствуют в разных регионах.
Кроме кэширования, у CDN есть приятный побочный эффект: если вдруг ваши сервера падают, CDN в некоторых случаях буферизуют запросы так, что пользователи этого могут и не заметить.
Основные заголовки
1. cache-control
Самый главный из всех. Обычно вы задаёте в строке его параметры, нечто вроде:
cache-control: private, max-age=0, no-cache
Эти настройки называются директивы ответа кэша, и они бывают следующие:
Сообщает, не является ли контент предназначенным для конкретного пользователя. Если это так, кэшировать его не нужно.
Сама по себе директива говорит, что этот запрос нужно каждый раз делать заново. Обычно используется заголовок etag, о котором ниже. Веселье начинается, когда вы задаёте имя поля после этой директивы. Тогда кэширующие сервера понимают, что ответ можно кешировать, но при этом надо удалять заданные поля. Это, например, полезно для правильной работы куков. Однако, некоторые старые программы не умеют работать с этим трюком.
Сообщает, что этот ответ не нужно хранить. Удивительно, но факт. Если кэш работает по правилам, он убедится, что никакая из частей запроса не будет храниться. Это нужно для того, чтобы обезопасить всякую чувствительную информацию.
Обычно время жизни ресурса задаётся через expires, но если вам надо быть более конкретным, можно задать max-age в секундах. И эта директива имеет преимущество над expires.
Немного похоже на предыдущую, однако s здесь означает shared cache, и нужна для CDN. Эта директива имеет преимущество над max-age и expires, когда речь идёт о CDN-серверах.
Говорит, что каждый запрос нужно делать заново, и ни при каких условиях не предоставлять пользователю закешированный контент. Имеет преимущество над всеми другими директивами, которые разрешают кэширование. В основном используется в некоторых особенных протоколах (к примеру, денежные переводы).
Некоторые прокси умеют сжимать и конвертировать контент для ускорения работы. Эта директива запрещает подобное поведение.
Примерно то же, что must-revalidate, но для промежуточных CDN-серверов. Почему её не назвали s-mustrevalidate? Кто его знает. Смысл в том, что проверять, не обновился ли контент, нужно для каждого нового пользователя только один раз.
2. expires
Изначально это был стандартный метод определения того, когда устаревает ресурс. Сегодня max-age и s-maxage имеют над ним преимущество, но всегда полезно задавать этот заголовок в целях обратной совместимости.
Задав дату, отстоящую более, чем на год, вы нарушите спецификацию заголовка.
3. etag
Сокращение от entity-tag. Это уникальный идентификатор запрашиваемого ресурса – обычно, некий хэш его содержимого, или хэш времени его обновления. В общем, способ клиента запросить у CDN «дай мне ресурс Х, если у него etag отличается от моего».
4. vary
Очень мощная штука. IE в прошлом обрабатывал его неправильно, да и сейчас не совсем корректно справляется. В какой-то момент даже Chrome с ним глючил. По сути, заголовок говорит системам кэширования, какие из заголовков можно использовать для определения того, допустимый ли у них в кэше лежит контент. Если рассматривать кэш как хранилище данных вида ключ-значение, то использование vary добавляет эти значения к ключам.
Часто можно встретить заголовок типа Accept-Encoding, который удостоверяется, что ваши ресурсы, сжатые gzip, будут приняты клиентом. Это здорово сберегает трафик. Кроме этого, настройка
сделает ваш сайт более дружественным к SEO, если вы раздаёте разные HTML/CSS в зависимости от User-Agent. Google заметит эту штучку и Googlebot будет обрабатывать и ваш мобильный контент.
5. pragma
Довольно старая директива, которая умеет делать много чего, что, однако, уже обрабатывается при помощи более современных. Нам более всего интересна форма
что в современных клиентах превращается в
Предостережения
Не все CDN или программы у клиентов работают согласно спецификациям. Если вы занимаетесь веб-разработкой, вам знакома эта проблема. Поэтому перед запуском сервиса всегда надо тестировать его, чтобы убедиться, что всё работает, как нужно.
Кроме того, вы могли заметить, что некоторые заголовки дублируют друг друга или их области применения перекрываются. Это происходит из-за небольших различий у разных методов, или из-за перехода веба с HTTP/1.0 на протокол HTTP/1.1, в котором кэширование расписано более подробно.
1. Сжатие
Провайдеры CDN, получающие запрос в gzip в качестве приемлемого сжатия, также должны запрашивать сжатый контент с сервера, или предоставлять клиенту сжатую версию ресурса. Современные CDN умеют проводить сжатие ресурсов самостоятельно.
При тестировании быстродействия серверов CDN нужно учесть, что некоторые настроены так, чтобы проверять наличие у себя как сжатой, так и несжатой версий ресурсов. Эта проверка слегка увеличивает время на реагирование.
2. SSL
CDN – это человек-в-середине. Вам нужно подумать об организации HTTPS-трафика и о том, как он идёт к вам на сервер. Многие CDN перенаправят запрос к somesite.com/asset на адрес somesite.com/asset, поэтому если логика вашего сервера зависит от протокола, либо поменяйте логику, либо попросите CDN сделать переадресацию на HTTPS.
А что же с динамическим контентом?
Обычно в этом случае надо задавать cache-control: no-cache, чтобы CDN не кэшировали его. Если вам интересно, как можно немного ускорить и его работу, продолжайте чтение.
Типичный динамический контент
Большая часть динамического контента не такая уж и непостоянная. Список активных пользователей, к примеру, имеет время жизни 10-20 секунд. Страницы с графиками наверняка могут пожить несколько минут. Новостная лента может некоторое время и покэшироваться, особенно при наличии etag. Если загрузка вашего сайта велика, стоит попробовать кэшировать ненадолго некоторые его ресурсу
Анализ времени кэширования
Так какое время для хранения ресурсов лучше задавать? Это зависит от количества трафика, размера ресурсов, размера кэша.
Кроме того, надо подумать о главном недостатке кэширования – уменьшении контроля над ресурсами. Если вам надо обновить ресурс мгновенно, у вас будут проблемы, если вы некоторое время назад задали ему время жизни в год. Особенно, если вы задали это время не только для CDN (s-maxage), но и для пользователей (max-age).
Самый длительный промежуток для кэша – год, или 31536000. Но это плохая идея. Это всё равно, что сделать татуировку на лице. Если ваши сервера не выдерживают хотя бы ежедневных запросов от CDN по поводу того, изменился ли ресурс,- пора менять сервера.
Заголовки для статичного контента
Пример настроек кэша для статичного контента с S3. Кэшу рекомендуется хранить ресурс 900 секунд, пользовательским программам – 300 секунд. Последний заголовок говорит о том, какой из CDN обработал запрос.
Одно исключение из заповеди «не кэшируй ресурсы на год», а точнее, один хак, позволяющий обойти проблемы долгого кэша. Вы можете переименовывать ресурс каждый раз, когда выпускаете новую его версию. К его имени может добавляться увеличивающийся номер версии, временной ярлык, хэш.
В следующей таблице отражается потеря времени на кэш. Предполагая, что ресурс получает 500 запросов в минуту, для разных вариантов времени хранения ресурса получаются следующий процент запросов к кэшу:
Учебное пособие по кэшированию, часть 2
Вторая часть довольно подробного и интересного изложения материала, касающегося кэша и его использования. Часть 1.
Автор, Mark Nottingham, — признанный эксперт в области HTTP-протокола и веб-кэширования. Является председателем IETF HTTPbis Working Group. Принимал участие в редактировании HTTP/1.1, part. 6: Caching. В настоящий момент участвует в разработке HTTP/2.0.
От переводчика: об опечатках и неточностях просьба сообщать в личку. Спасибо.
Как (и как не) управлять кэшем
Существует несколько инструментов, которые веб-дизайнеры и веб-мастера могут использовать для тонкой настройки того, как кэш будет работать с их сайтами. Это может потребовать от вас небольшого ознакомления с конфигурацией сервера, но оно того стоит. Для получения более детальной информации о том, как использовать эти инструменты для работы с вашим сервером, обратитесь к разделам “Реализация” (прим. переводчика — будет в следующей части) ниже.
Мета-теги HTML и HTTP-заголовки
Специалисты, работающие с HTML, могут поместить определенные теги в раздел HTML-документа, в котором описываются такого рода атрибуты. Мета-теги часто используются в надежде, что они помогут пометить документ как некэшируемый или устаревающий в определенное время.
С другой стороны, верные HTTP-заголовки дают вам серьезный контроль над тем, как и кэш браузера, и прокси обрабатывают ваш контент. Они не могу быть рассмотрены в HTML и, обычно, автоматически генерируются на стороне веб-сервера. Однако, вы можете управлять ими в некоторой степени, в зависимости от используемого сервера. В следующих разделах вы увидите, какие HTTP-заголовки представляют интерес, и как их применить на своем сайте.
HTTP-заголовки отправляются сервером прежде HTML и рассматриваются только браузером и любым промежуточным кэшем. Заголовки типичного HTTP/1.1 ответа могут выглядеть следующим образом:
HTTP/1.1 200 OK
Date: Fri, 30 Oct 1998 13:19:41 GMT
Server: Apache/1.3.3 (Unix)
Cache-Control: max-age=3600, must-revalidate
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT
ETag: «3e86-410-3596fbbc»
Content-Length: 1040
Content-Type: text/html
Примечание
Если ваш сайт размещен у интернет-провайдера (ISP) или на хостинг-ферме и они не позволяют вам устанавливать произвольные HTTP-заголовки (такие как Expires и Cache-Control ), упорнее выражайте недовольство; это инструменты, необходимые для вашей работы.
HTTP-заголовки Pragma (и почему они не работают)
Контроль свежести HTTP-заголовком Expires
Большинство веб-серверов позволяют установить заголовки ответов Expires с помощью ряда методов. Как правило, они позволяют установить абсолютно точное время истечения; время, на основе последнего раза, когда клиент запрашивал контент (last access time); или время, основанное на дате последнего изменения документа на сервере (last modification time).
Например:
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Хотя заголовок Expires полезен, он имеет некоторые ограничения. Во-первых, часы веб-сервера и кэша должны быть синхронизированы, так как в расчетах присутствует время; если у них разное представление о текущих дате/времени, ожидаемый эффект не будет достигнут и кэш может ошибочно трактовать устаревший контент как свежий.
Примечание
HTTP-заголовки Cache-Control
Валидаторы и валидация
В секции “Как работает кэш” мы сказали, что валидация используется серверами и кэшами для взаимодействия, когда контент был изменен. Используя её, кэш избегает необходимости скачивания контента целиком, когда он уже имеет локальную копию, но не уверен в том, что она все еще свежая.
Валидаторы очень важны; если нет ни одного и не доступна любая информация о свежести ( Expires или Cache-Control ), кэш не будет хранить контент вообще.
Почти все кэши используют время из Last-Modified как валидатор; ETag также становятся распространенными.
Советы по построению дружественных кэшу сайтов
Помимо использования свежести и валидации, существует ряд других мер, которые вы можете выполнять, чтобы сделать ваш сайт более дружественным кэшу.
Написание скриптов, дружественных кэшу
Вообще говоря, если скрипт производит некий вывод, который является воспроизводимым тем же запросом позднее (неважно, через минуты или дни), он должен быть закэширован. Если контент на выходе сценария изменяется только в зависимости от того, что в URL-адресе, он кэшируется; если вывод зависит от куков, информации об аутентификации или от какого-то другого внешнего фактора, вероятно кэширования не происходит.
Основы клиентского кэширования понятными словами и на примерах. Last-modified, Etag, Expires, Cache-control: max-age и другие заголовки
Кэш играет важную роль в работе практически любого веб-приложения на уровне работы с базами данных, веб-серверами, а также на клиенте.
В рамках этой статьи мы попытаемся разобраться с клиентским кэшированием. В частности, разберемся с тем, какие http-заголовки используются браузерами и веб-серверами и что они значат.
Но для начала давайте выясним, зачем вообще нужно кэширование на стороне клиента?.
Веб-страницы состоят из множества различных элементов: картинок, css и js файлов и т.п. Часть этих элементов используются на нескольких (многих) страницах сайта. Под клиентским кэшированием понимают способность браузеров сохранять копии файлов (ответов сервера), чтобы не загружать их повторно. Это позволяет значительно ускорить повторную загрузку страниц, сэкономить на трафике, а также снизить нагрузку на сервер.
Существует несколько различных HTTP-заголовков для того, чтобы управлять процессами кэширования на стороне клииента. Давайте поговорим о каждом из них.
Http заголовки для управления клиентским кэшированием
Для начала давайте посмотрим, как сервер и браузер взаимодействуют при отсутствии какого-либо кэширования. Для наглядного понимания я попытался представить и визуализировать процесс общения между ними в виде текстового чата. Представьте на несколько минут, что сервер и браузер – это люди, которые переписываются друг с другом 🙂
Без кэша (при отсутствии кэширующих http-заголовков)
Как мы видим, каждый раз при отображении картинки cat.png браузер будет снова загружать ее с сервера. Думаю, не нужно объяснять, что это медленно и неэффективно.
Идея заключается в том, что сервер добавляет заголовок Last-modified к файлу (ответу), который он отдает браузеру.
Таким образом, используя Last-modified мы экономим на загрузке большого файла, отделываясь пустым быстрым ответом от сервера.
Подробнее о ETag можно почитать здесь.
Заголовок Expired
В следующий раз браузер, зная, что “дата истечения срока годности” еще не наступила, даже не будет пытаться делать запрос к серверу и отобразит файл из кэша.
Такой вид кэша особенно актуален для иллюстраций к статьям, иконкам, фавиконкам, некоторых css и js файлов и тп.
public
Дело в том, что кэшировать запросы может не только конечный клиент пользователя (браузер), но и различные промежуточные прокси, CDN-сети и тп. Так вот, директива public позволяет абсолютно любым прокси-серверам осуществлять кэширование наравне с браузером.
private
Директива говорит о том, что данный файл (ответ сервера) является специфическим для конечного пользователя и не должен кэшироваться различными промежуточными прокси. При этом она разрешает кэширование конечному клиенту (браузеру пользователя). К примеру, это актуально для внутренних страниц профиля пользователя, запросов внутри сессии и т.п.
no-store
Указывает клиенту, что он не должен сохранять копию запроса или частей запроса при любых условиях. Это самый строгий заголовок, отменяющий любые кэши. Он был придуман специально для работы с конфиденциальной информацией.
must-revalidate
Эта директива предписывает браузеру делать обязательный запрос на сервер для ре-валидации контента (например, если вы используете eTag). Дело в том, что http в определенной конфигурации позволяет кэшу хранить контент, который уже устарел. must-revalidate обязывает браузер при любых условиях делать проверку свежести контента путем запроса к серверу.
Как посмотреть, какие заголовки используются на сайте?
Вы можете посмотреть заголовки http-запросов (request headers) и ответов (response headers) в отладчике Вашего любимого браузера. Вот например, как это выглядит в хроме:
То-же самое можно увидеть в любом уважающем себя браузере или http-сниффере.
Настройка кэшировения в Аpache и Nginx
Мы не будем пересказывать документацию по настройке популярных серверов. Вы всегда можете посмотреть ее здесь для Nginx и здесь для Apache. Ниже мы приведем несколько примеров из жизни для того, чтобы показать, как выглядят файлы конфигурации.
Пример конфигурации Apache для контроля Expires
Выставляем различный “срок годности” для различных типов файлов. Один год для изображений, один месяц для скриптов, стилей, pdf и иконок. Для всего остального – 2 дня.
Пример конфигурации Nginx для контроля Expires
Выставляем различный “срок годности” для различных типов файлов. Одна неделя – для изображений, один день – для стилей и скриптов.
Пример конфигурации Apache для Cache-control (max-age и public/private/no-cache)
Пример конфигурации Nginx для Cache-control статических файлов
В заключение
“Кэшировать все то, что можно кэшировать” – хороший девиз для веб-разработчика. Иногда можно потратить всего несколько часов на конфигурацию и при этом значительно улучшить восприятие вашего сайта пользователем, значительно сократить нагрузку на сервер и сэкономить на трафике. Главное – не переусердствовать и настроить все правильно с учетом особенностей Вашего ресурса.
Будем благодарны за рекомендации и поправки в комментариях и не забудьте поделиться статьей с друзьями, если она Вам понравилась 😉
HTTP-кеширование
Из всех байтов, суетящихся в Интернете в любой момент, подавляющее большинство из них являются статическими или вряд ли изменятся со временем. Изображения, видео и шрифты все попадают в эту категорию, и к этим ресурсам можно отнести множество проблем производительности современного интернета.
Проблема не обязательно в том, что эти ресурсы велики или что они неоптимизированы, а в том, что многим веб-приложениям нужно извлекать их при каждом обновлении страницы. Если бы пользователи могли тратить меньше времени на загрузку вашего великолепного изображения героя Unsplash и больше времени на рендеринг HTML и анализ JavaScript, они бы столкнулись с более быстрым приложением.
Основы кэширования
Идеальный кеш позволил бы клиенту, такому как браузер, как можно дольше удерживать ресурс, прежде чем выбросить его для более новой версии, когда это необходимо. Легко сказать, но это одна из «двух сложных проблем» в информатике.
Для того чтобы кэш функционировал, вам нужен способ указать, как долго ресурс будет свежим, что является невыполнимой задачей для сервера, поскольку он не может с абсолютной уверенностью предсказать, когда (если вообще когда-либо) будет обновлен ресурс. Этими знаниями обладаете только вы, как разработчик.
Как это сделать? HTTP предлагает два основных средства, первое из которых мы сейчас рассмотрим.
Expires и истоки кеширования HTTP
По истечении указанного срока Expires браузер попытается повторно получить указанный ресурс. До этого браузер может свободно удерживать ресурс и использовать его по своему усмотрению.
Повторная проверка с Last-Modified и If-Modified-Since
Введите If-Modified-Since. Расширяя наш пример выше, представьте, что браузер хотел получить image.jpeg 15 апреля, на следующий день после даты, указанной в Expires заголовке. Вы заметите, что приведенный выше фрагмент кода содержит Last-Modified заголовок, который указывает, когда сервер в последний раз полагал, что изображение было обновлено.
Учитывая, что браузер уже имеет image.jpeg в своем кэше, он может сообщить серверу, что у него уже есть копия изображения, которое было изменено в последний раз 12 апреля:
Если изображение изменилось, сервер просто ответит полным ответом, содержащим новое изображение. В противном случае он может ответить 304 Not Modified :
После получения такого ответа браузер может выпустить свою кэшированную копию. Этот результат является выигрышным как для сервера, так и для клиента: сервер гарантирует, что используется самая последняя версия ресурса, и клиенту не нужно повторно загружать образ.
cache-control и эволюция HTTP-кеширования
Ограничения Expires привели к появлению cache-control в HTTP/1.1, что значительно увеличило гибкость, с которой разработчики могли кэшировать ресурсы. Вместо того, чтобы строго полагаться на даты, cache-control принимает ряд директив, пару из которых мы обсудим сейчас, а остальные сворачиваются в дискуссии о повторной проверке, безопасности и многом другом.
Директива max-age
Обратите внимание, что max-age относится ко времени запроса, поэтому таймер начинает отсчитывать время, когда ресурс входит в кеш. Вы можете спросить: «Зачем переходить на секунды по датам?»
Мало того, что может быть трудно сопоставить дату Expires с вашим местным часовым поясом, многие реализации сервера просто испортили формат даты, что привело к путанице. max-age будучи простым целым числом, представляющим секунды с момента генерации ответа, гораздо проще использовать.
Повторная проверка с Etag и If-None-Match
Вы можете рассматривать теги сущностей как способ, с помощью которого серверы могут однозначно идентифицировать версию ресурса с помощью буквенно-цифрового идентификатора, указанного в заголовке ответа ETag :
Если клиент хочет сообщить серверу, что у него есть конкретная версия ресурса, он предоставляет заголовок запроса If-None-Match при следующем запросе ресурса:
Именно эта конкретная проблема приводит к тому, что популярные хранилища, такие как S3, используют алгоритмы хеширования, например, md5 для создания тегов сущностей. Используя теги сущностей, привязанные к фактическому дайджесту байтов, составляющих ресурсы, вы получаете идентификатор, уникальный для этого файла.
Обеспечение конфиденциальности кэша с помощью private и public
До этого момента мы фокусировались на кеше, который существует в вашем браузере, который кэширует ресурсы по мере их загрузки. Но реальность такова, что ресурсы часто проходят через один или несколько промежуточных или «общих» кэшей, прежде чем они попадают в ваш браузер. Это могут быть кеши, используемые вашим интернет-провайдером или корпоративным ИТ-отделом.
До того, как HTTPS получил широкое распространение, многие промежуточные кэши стали использовать ресурсы в случае, если другой пользователь может найти это полезным. Не нужно много воображения, чтобы увидеть, это может быть не так.
Подавление кэширования с помощью no-cache и no-store
HTTP / 1.1 исправил недостаточность заголовка Pragma в HTTP / 1.0 и предоставил веб-разработчикам средства, с помощью которых можно полностью отключить кэширование.
Вторая директива, no-store это молоток: она сигнализирует, что ресурс ни в коем случае не должен входить в кеш.
Указание специфичных для запроса ограничений кэширования
Что если в качестве клиента вы захотите запросить ресурс, который будет обновлен хотя бы в течение определенного периода времени? Хорошая новость заключается в том, что cache-control это не только инструмент для серверов, задающий ограничения кэширования для клиентов, но и доступный для клиентов, чтобы они могли получить ресурс, который соответствует определенным требованиям к кэшированию.
В дополнение к указанным выше директивам, в cache-control в вашем распоряжении четыре директивы только для запроса.
Vary и согласованные с сервером ответы
Наша последняя тема посвящена тому, как браузеры на самом деле идентифицируют ресурсы, и как согласование сервера влияет на ситуацию.
На высоком уровне кэш браузера действительно просто смотрит на URL и метод, хотя практически все кешируемые запросы являются запросами GET, практическая реальность такова, что URL, как правило, достаточно, чтобы браузеры идентифицировали ресурсы.
Это начинает разрушаться, когда мы понимаем, что два ответа, обслуживаемых для одного и того же URL, могут отличаться в зависимости от агента пользователя или использовать разные стратегии сжатия.