Cloudflare добавила поддержку HTTP-заголовка Vary для кэшируемых ответов. Об этом стало известно из комментария разработчика Саймона Уиллисона в обсуждении Hacker News, опубликованного 23 сентября 2026 года. По его словам, такой возможности он ждал от Cloudflare несколько лет.
Новость не относится напрямую к выпуску новой языковой модели или AI-продукта. Однако изменение затрагивает инфраструктурный слой, на котором работают веб-интерфейсы, API, панели управления и сервисы с машинно-генерируемыми ответами. Ошибка в настройке Vary может привести к тому, что кэш отдаст пользователю не тот формат ответа, который был запрошен.
Какую проблему решает Vary
HTTP-заголовок Vary сообщает промежуточному кэшу, какие заголовки запроса влияют на содержимое ответа. Если сервер формирует разные версии страницы в зависимости от значения Accept, он может вернуть HTML для запроса с `Accept: text/html` и JSON для другого клиента.
Без учета Vary кэш видит один URL и может сохранить первый полученный ответ как универсальный. Если первым пришел запрос за JSON, следующий пользователь, ожидающий HTML, рискует получить JSON. Обратная ситуация также возможна: веб-клиенту может достаться HTML вместо структурированных данных.
В типичном ответе сервер указывает, например:
`Vary: Accept`
Это означает, что кэш должен различать варианты ответа по заголовку Accept, а не считать их одной и той же копией ресурса. На практике список вариантов может быстро расти: помимо Accept, приложение иногда учитывает язык, кодировку, тип устройства или другие параметры запроса.
Именно поэтому Vary считается сложной частью HTTP-кэширования. Он влияет не только на корректность ответа, но и на количество объектов в кэше, долю попаданий и итоговую нагрузку на исходный сервер. Описание механизма приведено в спецификации HTTP Semantics: https://httpwg.org/specs/rfc9110.html#field.vary
Что изменилось у Cloudflare
В комментарии Уиллисон описал прежнее ограничение Cloudflare: по его словам, сеть не учитывала Vary для большинства типов содержимого и делала исключение для изображений. Из-за этого схема с одним URL для разных представлений ответа считалась рискованной при включенном кэшировании.
Главный риск — не сбой приложения как таковой, а смешивание представлений между пользователями. Сервер может правильно сформировать JSON, а проблема возникнет позднее, когда CDN выдаст сохраненный ответ другому клиенту. Для публичных API это означает вероятность получить страницу в формате, который не соответствует ожиданиям клиента. Для внутренних сервисов последствия зависят от конфигурации доступа и характера данных.
Поддержка Vary должна сделать такую архитектуру более предсказуемой: Cloudflare сможет разделять кэшированные ответы по указанному в заголовке параметру. При этом из исходного сообщения не следует, что любое приложение автоматически станет безопасным после включения функции. Сервер по-прежнему должен корректно выставлять заголовки, а разработчику нужно проверить правила кэширования и поведение конкретного маршрута.
Подробности следует сверять с документацией Cloudflare по кэшированию и заголовкам управления кэшем: https://developers.cloudflare.com/cache/
Почему это важно для AI-сервисов
AI-приложения часто используют несколько представлений одного ресурса. Веб-интерфейс может запрашивать HTML, программный клиент — JSON, а отдельный маршрут — потоковый ответ для постепенной выдачи результата. На уровне приложения это могут быть разные обработчики, но иногда разработчики выбирают один URL и определяют формат по заголовкам запроса.
Такой подход удобен для клиентов, которым не нужно запоминать разные адреса. Одновременно он усложняет работу CDN: кэш должен понимать, какие части запроса влияют на ответ. Если этого не происходит, ускорение за счет кэша превращается в источник трудноуловимых ошибок.
Особенно осторожно нужно обращаться с ответами AI-систем. В отличие от статического файла, результат генерации может зависеть от авторизации, истории диалога, системных параметров или пользовательского контекста. Даже корректный учет Accept не делает безопасным кэширование персонализированного ответа. Для таких маршрутов требуется отдельно проверять, разрешено ли кэширование вообще и не должен ли ответ содержать `Cache-Control: private` или `no-store`.
Поддержка Vary решает только задачу различения представлений по заявленным заголовкам. Она не заменяет контроль доступа, защиту персональных данных и проверку того, какие параметры действительно участвуют в формировании ответа.
Почему единый URL не всегда лучший выбор
Уиллисон отдельно отметил, что после появления этой возможности он все равно предпочитает не использовать описанную схему. В собственных приложениях он выбирает предсказуемые URL: HTML возвращается по одному адресу, а JSON — по адресу с суффиксом `.json`.
У такого решения есть практический недостаток: API получает больше явных маршрутов, а клиенту нужно знать, какой URL использовать. Зато формат ответа становится виден из адреса, и поведение проще тестировать через браузер, командную строку, прокси и CDN.
Суффикс `.json` также снижает зависимость от тонкостей согласования содержимого. Разработчику не приходится полагаться только на то, что все промежуточные компоненты одинаково интерпретируют Vary. Это не отменяет необходимость корректных HTTP-заголовков, но уменьшает число вариантов, которые должен различать кэш.
Для AI-сервиса выбор зависит от архитектуры. Если один ресурс действительно должен обслуживать HTML и JSON, необходимо проверить Vary в реальном окружении. Если API и веб-интерфейс имеют разные жизненные циклы, явные маршруты обычно проще сопровождать.
Что проверить разработчикам
Перед включением кэширования для маршрута стоит отправить один и тот же URL как минимум с разными значениями Accept и сравнить:
- заголовок `Content-Type`;
- наличие и значение `Vary`;
- заголовки `Cache-Control`;
- статус `Age` или другие признаки ответа из CDN;
- тело ответа после повторного запроса с другим форматом.
Практический тест должен выполняться через публичный адрес за Cloudflare, а не только локально или напрямую к исходному серверу. Сначала можно запросить HTML, затем JSON, после чего снова запросить HTML и убедиться, что ответы не поменялись местами. Для потоковых AI-ответов дополнительно нужно проверить, не ломает ли промежуточный кэш передачу данных и не сохраняется ли персонализированный результат.
Сообщение Уиллисона подтверждает изменение и описывает прежнюю проблему, но не содержит полного перечня ограничений Cloudflare, правил для всех типов ответов и рекомендаций для конкретных тарифов. Поэтому разработчикам следует сверяться с актуальной документацией и тестировать собственную конфигурацию, а не считать поддержку Vary универсальным разрешением кэшировать HTML, JSON или ответы AI-моделей по одному URL.
