Заголовок ответа Vary называют «самой неприятной частью HTTP, которую мы до сих пор не улучшили». В той же статье он описывается как «ужасный, неуклюжий механизм» с «весьма удручающей совместимостью» между промежуточными агентами. Обычно на этом этапе здравомыслящие инженеры медленно отступают назад, подняв руки.

Это не совсем похвала в адрес Vary, но неприятный не значит бесполезный.

Один URL-адрес может иметь более одного корректного ответа. Сервер может, например, выдавать разные форматы изображений разным браузерам. Если кэш игнорирует Vary, он рискует выдать не те байты в ответ на запрос. Но если он рассматривает каждое сырое значение заголовка как уникальное, горстка похожих запросов может превратиться в тысячи едва ли пригодных для повторного использования записей кэша. Vary сообщает кэшу, какие поля запроса могут влиять на ответ, но он не говорит кэшу, какие различия действительно важны.

Поддержка Vary теперь доступна в Правилах кэширования (Cache Rules) на любом тарифном плане. Исходный сервер по-прежнему указывает заголовки запроса, которые могут влиять на ответ, но вы сами решаете, как Cloudflare обрабатывает каждый из них. Вы можете нормализовать известные заголовки согласования, передавать точные значения дальше, когда эти мелкие различия имеют значение, или обходить кэш, если вариативность слишком непредсказуема. Исходный сервер заявляет, что может изменяться, а вы решаете, какая степень вариативности действительно имеет значение для кэша.

Как работает Vary

Vary — это стандартный заголовок ответа HTTP, который сообщает промежуточным кэшам (таким как Cloudflare), какие поля запроса могут повлиять на ответ, отправленный исходным сервером. Сайты используют Vary для предоставления разных языков, форматов изображений, схем сжатия или регионального контента с одного и того же URL-адреса.

Возьмем один URL-адрес, который выдает два допустимых варианта представления. Браузер запрашивает веб-страницу:

Исходный сервер возвращает HTML и указывает Accept как поле, которое может повлиять на ответ:

Клиент API может запросить тот же URL с другими предпочтениями:

На этот раз правильным ответом является JSON. Заголовок Vary: Accept сообщает кэшу, что одного лишь URL недостаточно для выбора между ответами. Также необходимо учитывать значение Accept в запросе.

Без Vary тот ответ, который попадает в кэш первым, может быть отправлен обоим клиентам. Если побеждает HTML, клиент API получает разметку, и его парсер JSON дает сбой. Если побеждает JSON, браузер, ожидающий веб-страницу, получает ответ API.

Vary предотвращает выдачу неправильного ответа запрашивающему клиенту со стороны кэша. Но это порождает более сложный вопрос: когда два запроса содержат разные значения заголовков, действительно ли им нужны разные ответы?

Когда правильное кэширование становится бесполезным

Vary может подсказать кэшу, какие поля запроса могут повлиять на ответ. Он не говорит кэшу, что представляет собой этот ответ. Например, возьмем исходный сервер, который обслуживает контент только на английском, французском и немецком языках. Один клиент может отправить:

В то время как другой клиент может запросить:

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

В этом и заключается главная проблема Vary. Приложения часто создают небольшой конечный набор представлений из огромного набора возможных значений запроса. Исходный сервер понимает, что тысячи языковых предпочтений сводятся к трем поддерживаемым языкам, в то время как кэш обычно этого не делает.

Эта проблема усугубляется, когда ответ варьируется по нескольким полям. Десять возможных значений в одном поле создают десять вариантов. Десять значений в трех полях могут создать 1000 комбинаций. Реальные заголовки могут иметь гораздо большую кардинальность: значений User-Agent множество, файлы cookie могут быть уникальными для каждого отдельного посетителя, а заголовки предпочтений могут различаться порядком, форматированием (пробелы и табуляции имеют значение!) и значениями качества.

В результате получается кэш, который может быть абсолютно корректным и почти постоянно холодным (запись никогда не используется повторно). Идентичные ответы могут быть разбросаны по записям, которые получают слишком мало трафика, чтобы оставаться горячими и находиться в кэше. Они могут потреблять емкость, вытеснять друг друга, снижать коэффициенты попадания в кэш и отправлять больше запросов обратно на исходные серверы. Вытеснение может удалить холодные записи, но оно не может объединить их просто потому, что ответы идентичны.

Анализ более 120 миллионов ответов почти с 50 000 популярных сайтов показал, что почти 3 000 сайтов варьируют контент по четырем или более полям. Некоторые варьировали по 10, 23 или даже 47 полям. Мы хотим убедиться, что у клиентов есть инструменты, необходимые для использования Vary в нужных случаях, но не настолько, чтобы они создавали бесполезный кэш.

Некоторая вариативность с высокой кардинальностью является преднамеренной. CDN или обратные прокси-серверы могут внедрять значения, такие как географический регион, для предсказуемого разделения контента. Это работает, когда возможные значения контролируются, и каждый компонент согласен с их значением. Без этих ограничений кэш фрагментируется на варианты, которые он может никогда не использовать повторно.

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

Как Правила кэширования (Cache Rules) управляют Vary

У клиентов Cloudflare уже было несколько способов обработки согласованного контента, аналогичного Vary. Они могли обходить кэш и позволять исходному серверу разбираться с этим, воспроизводить логику согласования исходного сервера в пользовательском ключе кэша или другом правиле, использовать Worker или использовать такие функции, как Vary для изображений.

Эти варианты остаются полезными, но они либо отказываются от кэширования, либо дублируют логику приложения, либо требуют написания дополнительного кода, либо решают более узкие задачи. Vary в Правилах кэширования может заполнить пробел между этими существующими функциями, разделив поддержку на два решения:

Исходный сервер использует Vary для идентификации заголовков запроса, которые могут повлиять на ответ.

Правило кэширования определяет, как Cloudflare обрабатывает значение каждого заголовка.

Правило кэширования не заставляет каждый ответ изменяться. Если исходный сервер не возвращает Vary, Cloudflare кэширует ответ обычным образом, хотя правило все равно может перезаписывать Accept и Accept-Language перед пересылкой запроса на исходный сервер.

Когда исходный сервер возвращает Vary, Cloudflare использует настроенное действие для каждого названного им заголовка. Заголовки без индивидуальной настройки используют действие правила по умолчанию. Доступны три действия:

Действие

Что делает Cloudflare

Лучше всего использовать для

нормализация

Нормализует заголовки запроса перед выбором кэшированного варианта, помогая эквивалентным запросам разделять кэшированный ответ. Применяет правила для конкретных заголовков к Accept, Accept-Language и Accept-Encoding. Для других заголовков он удаляет лишние пробелы и объединяет повторяющиеся строки заголовков в их исходном порядке, сохраняя регистр и пробелы внутри.

Рекомендуемая отправная точка для заголовков согласования, где множество значений запроса сопоставляется с небольшим набором ответов.

проход без кэширования

Использует необработанные байты заголовка запроса для сопоставления с кэшем, сохраняя регистр, пробелы, порядок и дублирующиеся значения. Если заголовок располагается на нескольких строках, Cloudflare объединяет эти строки по порядку, используя запятые для сопоставления с кэшем. Режим passthrough оставляет исходящие строки заголовков без изменений. Cloudflare все равно может перезаписывать заголовок Accept-Encoding, когда параметр Respect Strong ETags отключен.

Заголовки с контролируемым набором значений, где точное значение изменяет ответ.

bypass

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

Используйте для персонализированных, высококардинальных или неожиданных заголовков, таких как Cookie или User-Agent.

Мы рекомендуем использовать normalize в качестве значения по умолчанию. Для отдельных заголовков с персональными или неограниченными значениями используйте bypass. Используйте passthrough, когда точное значение изменяет ответ.

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

X-View: compact,full

X-View: Compact,full

X-View: compact, full

Достаточное количество случайных вариаций может превратить один многократно используемый ответ в множество разовых вариантов в вашем кэше.

Независимо от настроенных действий, Vary: * всегда обходит кэш. Это означает, что любой аспект запроса, даже информация вне сообщения HTTP (например, IP-адрес клиента), может повлиять на то, какой ответ выберет источник. Следовательно, Cloudflare не может повторно использовать ответ для последующего запроса без обращения к источнику.

Как ответ проходит через кэш

Давайте проследим за одним из запросов /catalog из примера выше через Cloudflare.

При первом запросе у Cloudflare нет сохраненных данных Vary для этого ресурса, поэтому происходит промах кэша (cache miss). Соответствующее правило кэширования (Cache Rule) может нормализовать настроенные поля до того, как Cloudflare свяжется с источником.

Это может произойти до того, как Cloudflare узнает, будет ли итоговый ответ содержать Vary. Правило кэширования определяет разрешенную нормализацию; ответ позже определяет, станут ли эти поля частью кэшированного варианта.

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

Источник отвечает следующим образом:

Vary: Accept, Accept-Language

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

Когда поступает другой запрос для /catalog, Cloudflare начинает с базового ключа кэша ресурса: как правило, URL плюс любые другие настроенные ключевые поля. Затем он считывает сохраненные поля Vary и применяет правило кэширования к этим заголовкам в новом запросе, чтобы определить совпадающий кэшированный вариант.

Предположим, они нормализуются до следующих значений:

Accept: text/html

Accept-Language: en,fr

Cloudflare использует эти значения для прямого поиска подходящего кэшированного варианта. Он не сравнивает запрос со всеми сохраненными вариантами по очереди.

Если подходящий вариант существует и является актуальным, запрос считается попаданием в кэш (cache hit). Если нет, Cloudflare отправляет запрос к источнику и может сохранить полученный ответ в качестве другого варианта.

Ответ источника замыкает цикл. Для каждого заголовка, указанного в Vary, Cloudflare использует действие, настроенное для этого заголовка, или действие правила по умолчанию, если заголовок не указан индивидуально:

Если ответ не содержит Vary, Cloudflare кэширует его обычным образом.

Если каждый указанный заголовок разрешается в normalize или passthrough, Cloudflare может сохранить ответ как кэшированный вариант.

Если какое-либо указанное поле использует bypass, Cloudflare не сохраняет ответ.

Если ответ содержит Vary: *, Cloudflare не сохраняет его.

Это возлагает большую ответственность на источник. Каждый кэшируемый ответ, который может отличаться в зависимости от полей запроса, должен стабильно возвращать соответствующий заголовок Vary, включая ошибки и резервные ответы. Если один ответ опускает его, Cloudflare может закэшировать этот ответ без вариативности, необходимая для его изоляции.

Ключи кэша на диаграмме являются концептуальными. Последующий запрос предполагает наличие актуального кэшированного ответа.

Любая очистка, направленная на кэшированный ресурс, охватывает все его варианты Vary. Существующие требования к очистке пользовательских ключей кэша остаются в силе.

Изменение конфигурации Vary не приводит к автоматической очистке существующего контента. Новая политика может создавать другие ключи кэша: запросы могут приводить к промахам и заполнению под новыми ключами, в то время как старые записи остаются, пока не истечет их срок или они не будут очищены.

Нормализация объединяет эквивалентные запросы

Помните запросы из примера выше, запрашивающие английский и французский языки?

Accept-Language: en-US, fr;q=0.8

Accept-Language: fr;q=0.8, en-GB

Оба запроса отдают предпочтение английскому языку, но passthrough рассматривал бы их как разные варианты. Если правило кэширования разрешает en, fr и de, нормализация сводит оба варианта к en,fr, позволяя им использовать общий кэшированный ответ.

Для этого Cloudflare приводит значения в Accept, Accept-Language и Accept-Encoding к нижнему регистру, а затем сортирует их по значению качества (начиная с наивысшего), используя алфавитный порядок для разрешения совпадений. Таким образом, порядок следования у клиента не влияет на ключ кэша. После сортировки Cloudflare удаляет параметры из элементов с ненулевым значением качества. Он также может удалять q=0 («неприемлемо») при сокращении языковых тегов или фильтрации до настроенных форматов и языков. Например, en-US;q=0 может превратиться в en. Используйте passthrough для Accept или Accept-Language, если источнику необходимо видеть эти исключения.

Вы также можете настроить правило так, чтобы сохранять только указанные медиатипы или языки в Accept и Accept-Language. Региональные языковые теги, такие как en-US, сокращаются до базового языка en, если не настроен полный тег. Это позволяет сопоставить нормализацию с форматами и языками, которые фактически обслуживает ваш источник.

Чтобы выбор источника соответствовал сопоставлению с кэшем, Cloudflare пересылает источнику нормализованные значения Accept и Accept-Language. Он также пересылает нормализованные значения Accept-Encoding, когда включен параметр Respect Strong ETags. Другие заголовки нормализуются только для сопоставления с кэшем.

Настройка Vary в правилах кэширования

В панели управления Cloudflare перейдите в раздел Caching > Cache Rules, создайте или отредактируйте правило, сделайте ответ пригодным для кэширования и добавьте настройку Vary. Задайте поведение по умолчанию, а затем добавьте заголовки, которые должен указывать ваш источник.

Такая же конфигурация доступна через Rulesets API на этапе http_request_cache_settings. Настройка по умолчанию выбирает резервное действие для заголовков, которые ваш источник указывает в Vary, но которые вы не настроили индивидуально.

В этом примере выполняется нормализация Accept и Accept-Language до настроенного набора форматов и языков. Действие нормализации по умолчанию также применяется к другим заголовкам, указанным в Vary:

Это полный текст запроса для метода PUT в точку входа этапа http_request_cache_settings. Запрос PUT заменяет каждое правило в этой точке входа. Если у вас уже есть правила кэширования (Cache Rules), включите их в массив rules или используйте вместо этого соответствующую операцию создания или обновления отдельного правила.

Если исходный сервер обслуживает одно представление для каждого типа медиа и языковой пары, существует шесть комбинаций контента. Это не ограничивает кэш шестью ключами. Порядок предпочтения, отсутствующие заголовки и значения, которые нормализуются до пустых, могут создавать больше вариантов. Поддерживайте набор небольшим и четко определяйте границы правила. После развертывания протестируйте один и тот же URL с разными значениями заголовков, которые должны нормализоваться до одного и того же кэшированного варианта. Отправляйте тестовые запросы с одного клиента, убедитесь, что они возвращают ожидаемый формат и язык, и проверьте заголовок CF-Cache-Status. Ищите попадания (hits), как только кэш будет заполнен, и исследуйте постоянные ответы с промахами (miss) или неожиданные ответы с обходом кэша (bypass).

Ограничения, дополнительные примеры и инструкции по настройке в Terraform см. в документации по Vary.

Почему бы не использовать настраиваемый ключ кэша?

В этот момент возникает очевидный вопрос: «почему бы не добавить Accept и Accept-Language в настраиваемый ключ кэша?»

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

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

Используйте настраиваемый ключ кэша, когда свойство запроса всегда определяет ресурс. Используйте Vary, когда исходный сервер объявляет один и тот же набор полей запроса для кэшируемых ответов. Избегайте размещения одного и того же заголовка в обоих местах, если только это дублирование не является намеренным и протестированным.

Используйте Vary в правилах кэширования уже сегодня!

Vary помогает решить очевидную проблему: один URL может иметь более одного правильного ответа. Но он ставит перед кэшем более сложную задачу: какие именно различия в запросах имеют значение? Источник знает, какие ответы он может предоставить. Кэш должен знать, какие запросы могут повторно использовать каждый ответ.

Vary в правилах кэширования соединяет эти два представления. Источник определяет поля запроса, которые могут повлиять на ответ. Вы решаете, следует ли нормализовать значения, использовать проброс (passthrough) для точных различий или исключить ответ из кэша.

Заголовок Vary никогда не был слишком неприглядным, чтобы быть полезным. Но ручная настройка поддерживаемых форматов и языков может подойти не для каждого приложения. Мы оцениваем, смогут ли идеи из устаревшего черновика Availability Hints сократить эту работу, позволяя источникам напрямую описывать обслуживаемые ими представления.

Vary в правилах кэширования доступен уже сегодня на тарифах Free, Pro, Business и Enterprise через панель управления Cloudflare, API наборов правил и Terraform.