From 18f9c9ad313802cbe2cb45e538bbb136da7c30ba Mon Sep 17 00:00:00 2001 From: "E.Gavrilov" Date: Thu, 3 Sep 2026 23:44:51 +0300 Subject: [PATCH] =?UTF-8?q?EDITORIAL-311:=20=D1=83=D0=BB=D1=83=D1=87=D1=88?= =?UTF-8?q?=D0=B8=D1=82=D1=8C=20=D1=81=D1=82=D0=B0=D1=82=D1=8C=D1=8E=20?= =?UTF-8?q?=D0=BE=20HTTP-=D0=BA=D1=8D=D1=88=D0=B8=D1=80=D0=BE=D0=B2=D0=B0?= =?UTF-8?q?=D0=BD=D0=B8=D0=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- editorial/agent-rewrites/311.json | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/editorial/agent-rewrites/311.json b/editorial/agent-rewrites/311.json index 0e161f0..7f11d9e 100644 --- a/editorial/agent-rewrites/311.json +++ b/editorial/agent-rewrites/311.json @@ -1,7 +1,7 @@ { "index": 311, "slug": "editorial-2019-05-mechanism-http-caching", - "title": "HTTP-кэш: почему правильный TTL всё равно отдаёт неправильный ответ", - "excerpt": "Кэш проверяет не только срок хранения. Разбираем ключ варианта, Vary, ETag и границы browser cache, proxy и CDN на наблюдаемом сценарии.", - "contentHtml": "

После релиза пользователь открывает знакомый адрес и видит старый JavaScript или вчерашний язык страницы. В ответе есть Cache-Control: max-age=60, поэтому команда ждёт обновления через минуту. Но один клиент получает новый файл, другой — старый, а CDN продолжает отвечать из своего кэша. Ошибка стоит дороже, чем лишний запрос: пользователь видит неверное состояние, релиз выглядит сломанным, а команда начинает очищать кэш вслепую.

\n

Причина часто не в числе 60. Кэш хранит представление ответа для конкретного запроса. На это представление влияют URL, query-параметры, заголовки, cookies и правила посредника. Cache-Control описывает свежесть и допустимое хранение. Он не исправляет неполный ключ, не различает личные данные и не заставляет каждый слой сети забыть старую запись.

\n

Тезис: срок не заменяет ключ

\n

У каждого кэшируемого ответа должны быть три понятных свойства: какой запрос выбирает ответ, как долго его можно использовать без проверки и как подтвердить, что сохранённое представление ещё подходит. В HTTP этим ролям обычно соответствуют ключ варианта, директивы Cache-Control и валидатор вроде ETag. Заголовок Vary сообщает, какие поля запроса участвовали в выборе представления.

\n

Представьте публичную страницу /catalog. Origin формирует русский или английский HTML по Accept-Language. Для русского запроса кэш сохранил ответ. Следующий английский запрос получит тот же ответ, если посредник использует только URL и не учитывает язык. Этот ответ может быть свежим по max-age, но он всё равно неверен для запроса. Увеличение или уменьшение TTL не меняет ошибочный ключ.

\n

Другая ситуация возникает у файла /assets/app.js. Если содержимое меняется, а имя остаётся тем же, длинный TTL закрепляет старый файл. Безопасный долгий срок требует нового URL при каждом изменении, например app.4f91.js. Здесь кэш не обязан угадывать выпуск: новый адрес отделяет новое представление от старого.

\n

Как кэш принимает решение

\n

Клиент отправляет запрос. Кэш ищет сохранённый ответ, который подходит этому запросу. Сначала он проверяет соответствие варианта. Затем оценивает свежесть. Свежий ответ можно вернуть без origin. Несвежий ответ не обязательно нужно загружать заново: кэш может отправить условный запрос с If-None-Match. Origin ответит 304 Not Modified, если представление не изменилось, или 200 с новым телом, если изменилось.

\n

ETag не очищает запись и не делает ответ свежим. Он позволяет сравнить сохранённое представление с текущим. no-cache тоже не означает «не хранить»: директива требует повторной проверки перед использованием. no-store запрещает хранение ответа в соответствии с правилами кэша. private ограничивает использование частным кэшем и подходит для ответа, который нельзя отдавать общему кэшу.

\n

У ответа может быть несколько точек наблюдения: приложение, reverse proxy, CDN и браузер. Заголовок, снятый на origin, не доказывает, что тот же заголовок дошёл до браузера. Посредник может изменить TTL, ключ или правило обхода. Поэтому проверка должна сравнивать один сценарий на каждой доступной границе.

\n

Учебный пример: два варианта одного URL

\n

Ниже приведены команды для безопасного тестового домена. Это учебный сценарий, а не результат измерения production. Он меняет только один вход — язык — и сохраняет тело и заголовки отдельно. В реальной команде замените адрес на тестовый URL без личных данных.

\n
# Запросы к origin: меняется только Accept-Language.\ncurl -sS -D /tmp/catalog-ru.headers -o /tmp/catalog-ru.html \\\n  -H 'Accept-Language: ru' https://origin.example.test/catalog\n\ncurl -sS -D /tmp/catalog-en.headers -o /tmp/catalog-en.html \\\n  -H 'Accept-Language: en' https://origin.example.test/catalog\n\n# Сначала сравниваем договор, затем тело.\ngrep -Ei '^(cache-control|vary|etag|age):' /tmp/catalog-ru.headers\ngrep -Ei '^(cache-control|vary|etag|age):' /tmp/catalog-en.headers\nsha256sum /tmp/catalog-ru.html /tmp/catalog-en.html\n\n# Учебная проверка сохранённого варианта.\ncurl -sS -D - -o /dev/null \\\n  -H 'Accept-Language: ru' \\\n  -H 'If-None-Match: "catalog-ru-v18"' \\\n  https://origin.example.test/catalog
\n

Если тела различаются по языку, в ответе ожидается Vary: Accept-Language либо эквивалентное явно настроенное правило cache key. Если origin возвращает один язык для обоих запросов, CDN пока не проверяем: источник уже нарушает ожидаемый контракт. Если origin корректен, а публичный адрес склеивает ответы, ищем расхождение в CDN или reverse proxy.

\n

Значение ETag в команде условное. Его нужно взять из предыдущего ответа для того же языка. Нельзя использовать русский валидатор для английского варианта. При неизменном русском представлении ожидаем 304 после повторной проверки. После изменения русского HTML ожидаем новый 200 и новый валидатор. Конкретный статус и заголовки нужно подтвердить на вашем стенде.

\n

Симптомы и действия

\n
Диагностика HTTP-кэша по наблюдаемому симптому
СимптомПричинаПроверкаДействие
После релиза старый JavaScriptПостоянный URL и длинный TTLСравнить URL из нового HTML и digest файлаДобавить fingerprint или сократить контракт свежести
Английский запрос получает русский HTMLЯзык не входит в вариант кэшаСделать два запроса с разным Accept-Language и сравнить VaryИсправить ключ варианта или отказаться от общего кэша
Всегда приходит полный ответ после истечения TTLНет валидатора или условный запрос не доходит до originПовторить запрос с прежним ETag и проверить путь через proxyНастроить устойчивый валидатор и проверить каждый слой
Публичный ответ отличается от originCDN переписывает заголовки или использует другой ключСнять одинаковые заголовки через origin и публичный адресСверить правило CDN с HTTP-контрактом origin
Данные одного пользователя видит другойПерсональный ответ попал в общий кэшПроверить Cookie, авторизацию и Cache-Control на тестовых сессияхВыбрать private, no-store или разделить публичную и личную части
\n

Иллюстрация ключа и свежести

\n
\"Схема
Кэш сначала выбирает подходящее представление, затем проверяет его свежесть. Только после этого срабатывает повторная проверка через валидатор.
\n

Порядок проверки

\n
  1. Выберите один тестовый URL и запишите допустимую давность ответа. Для цены, HTML, asset и личных данных это могут быть разные правила.
  2. Выпишите все входы, которые меняют тело: query, язык, кодирование, cookie, авторизацию, эксперимент или географию.
  3. Снимите ответ origin и публичный ответ одним методом. Сохраните статус, тело или его digest, Cache-Control, ETag, Vary и Age, если поле есть.
  4. Проверьте два безопасных варианта, меняя только один вход. Разные тела требуют разных вариантов; одинаковые тела не требуют добавлять Vary по предположению.
  5. Дождитесь истечения выбранного срока на тестовом стенде или используйте короткий TTL. Повторите запрос с прежним ETag и зафиксируйте ожидаемый 304 либо новый 200.
  6. После изменения правила повторите тот же сценарий через origin, proxy, CDN и браузер, если эти границы доступны. Не очищайте кэш до первого снимка: иначе исчезнет доказательство исходного поведения.
  7. Проверьте отрицательный путь: персональный ответ, неизвестный язык, изменение asset и запрос без валидатора. Для каждого случая заранее запишите безопасный результат.
\n

Ограничения

\n

Эта модель объясняет HTTP-контракт, но не знает настройки конкретного CDN. Поставщик может иметь собственный cache key, отдельный TTL и правила обхода. Браузер может показать результат навигационной истории или service worker, а не обычного HTTP-кэша. Заголовок Age может отсутствовать и не доказывает отсутствие хранения. Поэтому один ответ curl не описывает весь маршрут пользователя.

\n

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

\n

Учебный пример не обещает конкретное ускорение и не доказывает работу вашей инфраструктуры. Проверяемый результат должен появиться только после запуска команд на контролируемом домене и сравнения ответов. Не публикуйте в диагностике токены, cookie, персональные query-параметры и внутренние адреса.

\n

Критерий готовности

\n

Работу можно считать завершённой, когда для каждого выбранного URL есть короткая карточка: входы, допустимая давность, ожидаемые директивы, валидатор и граница, на которой это проверяется. Два запроса с разными входами не смешивают тела. После истечения срока неизменённое представление даёт ожидаемую условную проверку, а изменённое — новый ответ. Новый asset получает новый URL. Персональный ответ не попадает в общий кэш. Если хотя бы один пункт нельзя показать заголовками и телом ответа, контракт ещё не доказан.

\n

Проверяемые источники

" + "title": "HTTP-кэш: почему правильный TTL не спасает ответ", + "excerpt": "Кэш проверяет не только срок свежести. Разбираем cache key, Vary, ETag и границы браузера, proxy и CDN на воспроизводимом сценарии.", + "contentHtml": "

После релиза пользователь открывает знакомый адрес и видит старый JavaScript или HTML не на том языке. В ответе есть Cache-Control: max-age=60, поэтому команда ждёт обновления через минуту. Но один клиент получает новый файл, другой — старый, а CDN продолжает отвечать из своей записи. Цена ошибки — неверное состояние страницы, лишняя нагрузка на origin и попытки очищать кэш вслепую.

\n

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

\n

Модель: ключ, свежесть и проверка

\n

В HTTP cache key как минимум включает метод и target URI запроса. Для обычных GET-кэшей на практике главным компонентом остаётся URI. Но origin может выбирать представление по заголовкам запроса, например по Accept-Language или Accept-Encoding. Тогда ответ должен сообщить об этом через Vary: кэш сравнивает названные поля текущего запроса с полями запроса, который породил сохранённый ответ.

\n

Управляемый CDN может добавить к ключу собственные признаки: cookies, географию, эксперимент или правило из панели. Это не отменяет HTTP-контракт. Заголовок, снятый на origin, не доказывает поведение публичного адреса: proxy или CDN может выбрать другую запись, изменить свежесть или отправить запрос дальше. Название настройки вроде «cache key» тоже не доказывает, какие поля реально участвуют в выборе.

\n

max-age задаёт срок, после которого ответ считают несвежим. Это не срок жизни записи и не команда удалить её. Несвежая запись может быть повторно проверена у origin. При совпавшем валидаторе origin для GET или HEAD обычно возвращает 304 Not Modified без нового тела; при изменении представления — 200 с новым телом и новым валидатором.

\n

Что именно делают директивы

\n

ETag сравнивает сохранённое представление с текущим. Он не очищает запись и сам по себе не делает её свежей. no-cache в ответе тоже не означает «не хранить»: перед повторным использованием кэш должен обратиться к origin для успешной проверки. no-store запрещает кэшу намеренно хранить ответ и использовать его для другого запроса, но не является полноценной защитой от скомпрометированного посредника.

\n

private запрещает хранение ответа в shared cache, но разрешает private cache пользователя при остальных условиях. Это подходит для персонализированного ответа, если его всё равно допустимо хранить в браузере. Для личного HTML часто безопаснее выбрать no-store. Для shared cache отдельный s-maxage задаёт максимальный возраст и переопределяет max-age для общего кэша; после истечения срок всё равно требует корректного правила повторной проверки.

\n

Из этого следует порядок решения: сначала совпадение URI, метода и варианта; затем допустимость повторного использования; затем свежесть; затем, если нужно, условный запрос к origin. Нельзя выводить причину по одному заголовку. Age полезен как признак того, что ответ был сгенерирован или проверен не для этого запроса, но отсутствие Age не доказывает обращение к origin.

\n

Учебный пример: язык меняет ответ

\n

Ниже приведён учебный сценарий для контролируемого домена. Он меняет только Accept-Language, сохраняет заголовки и тело отдельно и не выдаёт результат за измерение production. Подставьте URL тестового origin и не используйте в команде настоящие cookies или токены.

\n
# Origin должен вернуть разные представления для двух языков.\ncurl -sS -D /tmp/catalog-ru.headers -o /tmp/catalog-ru.html -H 'Accept-Language: ru' https://origin.example.test/catalog\ncurl -sS -D /tmp/catalog-en.headers -o /tmp/catalog-en.html -H 'Accept-Language: en' https://origin.example.test/catalog\n\n# Сначала сравниваем контракт, затем тела.\ngrep -Ei '^(cache-control|vary|etag|age|date):' /tmp/catalog-ru.headers\ngrep -Ei '^(cache-control|vary|etag|age|date):' /tmp/catalog-en.headers\nsha256sum /tmp/catalog-ru.html /tmp/catalog-en.html\n\n# Валидатор берём из ответа того же варианта.\ncurl -sS -D - -o /dev/null -H 'Accept-Language: ru' -H 'If-None-Match: "catalog-ru-v18"' https://origin.example.test/catalog
\n

Если origin действительно выбирает HTML по языку, для общего HTTP-кэша ожидается Vary: Accept-Language. Отдельное vendor-specific правило cache key может быть нужно CDN, но оно не заменяет заголовок для других посредников. Если origin отдал одинаковые тела, сначала исправьте выбор представления у источника: проверка CDN только замаскирует проблему.

\n

Значение ETag в команде условное. В рабочем запуске его нужно скопировать из предыдущего ответа для русского варианта, сохранив кавычки. Нельзя использовать русский валидатор для английского. Если представление не менялось и запрос дошёл до origin, ожидаем 304; при изменении тела ожидаем новый 200. Статус нужно зафиксировать на вашем стенде, а не обещать заранее.

\n

Симптомы и действия

\n
Диагностика HTTP-кэша по наблюдаемому симптому
СимптомГипотезаПроверкаДействие
После релиза старый JavaScriptПостоянный URL и длинный TTLСравнить URL из нового HTML и digest файлаДобавить fingerprint или изменить контракт свежести
Английский запрос получает русский HTMLНет Vary или CDN не учитывает вариантСделать два запроса, сравнить тела и заголовки на origin и public URLСогласовать выбор представления, Vary и cache key
После TTL всегда приходит полный ответНет валидатора или условный запрос не доходит до originПовторить запрос с прежним ETag и проверить маршрутНастроить устойчивый валидатор и проверить каждый слой
Публичный ответ отличается от originProxy или CDN меняет ключ, TTL или заголовкиСнять одинаковые поля и digest через обе точкиСверить конфигурацию посредника с HTTP-контрактом
Данные одного пользователя видит другойПерсональный ответ попал в shared cacheПроверить две тестовые сессии, Authorization, cookies и директивыВыбрать private, no-store или разделить публичную и личную части
CDN обслуживает запись дольше браузераИспользуется s-maxage, отличный от max-ageСравнить Age, Cache-Control и vendor headersЗафиксировать отдельную политику shared cache и критерий purge
\n

Иллюстрация ключа и свежести

\n
\"Схема
Кэш сначала выбирает подходящее представление по ключу, затем проверяет свежесть. Только после этого для несвежего ответа начинается повторная проверка через валидатор.
\n

Порядок проверки

\n
  1. Выберите один тестовый URL и опишите, какой ответ считается публичным, а какой персональным. Для HTML, asset и API правила могут различаться.
  2. Запишите метод и все входы, которые могут менять тело: query, язык, кодирование, cookie, авторизацию, эксперимент или географию. Отдельно отметьте, какие из них реально входят в cache key.
  3. Снимите ответ origin и публичный ответ одним методом. Сохраните статус, digest тела, Cache-Control, ETag, Vary, Age и Date, если поля есть.
  4. Проверьте два варианта, меняя только один вход. Если тела различаются, найдите правило, которое разделяет их; если одинаковы, не добавляйте Vary по предположению.
  5. Сопоставьте max-age и, если он используется, s-maxage. Не называйте истечение TTL удалением записи: оно может привести к условному запросу, а не к загрузке нового тела.
  6. Повторите запрос после истечения срока с валидатором именно того варианта. Зафиксируйте 304, новый 200 или иной фактический ответ и объясните его по заголовкам.
  7. Сравните origin, reverse proxy, CDN и браузер, если эти границы доступны. Для браузера отдельно исключите service worker и историю навигации. Не очищайте кэш до первого снимка.
  8. Проверьте отрицательный путь: персональный ответ, неизвестный язык, изменение asset и запрос без валидатора. Для каждого заранее запишите безопасный ожидаемый результат.
\n

Ограничения

\n

HTTP задаёт правила кэша, но не описывает конфигурацию каждого CDN. Посредник может иметь отдельный cache key, TTL, stale policy и операцию purge. Браузер может показать данные из service worker или навигационной истории, а не из обычного HTTP-кэша. Поэтому один ответ curl не описывает весь путь пользователя.

\n

Vary не заменяет проверку персонализации. Если тело зависит от cookie, эксперимента или пользователя, попытка перечислить все поля дробит кэш и может оставить риск утечки. Для личного HTML безопаснее начать с private или no-store, а публичную локализацию ограничить известным списком вариантов.

\n

Учебный домен, хэш файла и значение ETag не являются результатами измерения. Стандарт не гарантирует конкретный hit ratio, ускорение или поведение vendor-specific purge. В диагностике нельзя публиковать токены, cookies, персональные query-параметры и внутренние адреса.

\n

Критерий готовности

\n

Проверку можно считать завершённой, когда для выбранного URL записаны входы, допустимая давность, владелец правила cache key, ожидаемые директивы, валидатор и граница, на которой каждый пункт проверяется. Два запроса с разными входами не смешивают тела. После истечения срока неизменённое представление даёт подтверждённую условную проверку, а изменённое — новый ответ. Новый asset получает новый URL. Персональный ответ не попадает в shared cache.

\n

Если это нельзя показать заголовками, телом и снимками на доступных границах, контракт ещё не доказан. Исправление начинается с уровня, где появилось расхождение: origin, proxy, CDN или браузер. Очистка кэша может убрать симптом, но не доказывает, что ключ и срок теперь согласованы.

\n

Проверяемые источники

" }