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": "<p>После релиза пользователь открывает знакомый адрес и видит старый JavaScript или вчерашний язык страницы. В ответе есть <code>Cache-Control: max-age=60</code>, поэтому команда ждёт обновления через минуту. Но один клиент получает новый файл, другой — старый, а CDN продолжает отвечать из своего кэша. Ошибка стоит дороже, чем лишний запрос: пользователь видит неверное состояние, релиз выглядит сломанным, а команда начинает очищать кэш вслепую.</p>\n<p>Причина часто не в числе 60. Кэш хранит представление ответа для конкретного запроса. На это представление влияют URL, query-параметры, заголовки, cookies и правила посредника. <code>Cache-Control</code> описывает свежесть и допустимое хранение. Он не исправляет неполный ключ, не различает личные данные и не заставляет каждый слой сети забыть старую запись.</p>\n<h2>Тезис: срок не заменяет ключ</h2>\n<p>У каждого кэшируемого ответа должны быть три понятных свойства: какой запрос выбирает ответ, как долго его можно использовать без проверки и как подтвердить, что сохранённое представление ещё подходит. В HTTP этим ролям обычно соответствуют ключ варианта, директивы <code>Cache-Control</code> и валидатор вроде <code>ETag</code>. Заголовок <code>Vary</code> сообщает, какие поля запроса участвовали в выборе представления.</p>\n<p>Представьте публичную страницу <code>/catalog</code>. Origin формирует русский или английский HTML по <code>Accept-Language</code>. Для русского запроса кэш сохранил ответ. Следующий английский запрос получит тот же ответ, если посредник использует только URL и не учитывает язык. Этот ответ может быть свежим по <code>max-age</code>, но он всё равно неверен для запроса. Увеличение или уменьшение TTL не меняет ошибочный ключ.</p>\n<p>Другая ситуация возникает у файла <code>/assets/app.js</code>. Если содержимое меняется, а имя остаётся тем же, длинный TTL закрепляет старый файл. Безопасный долгий срок требует нового URL при каждом изменении, например <code>app.4f91.js</code>. Здесь кэш не обязан угадывать выпуск: новый адрес отделяет новое представление от старого.</p>\n<h2>Как кэш принимает решение</h2>\n<p>Клиент отправляет запрос. Кэш ищет сохранённый ответ, который подходит этому запросу. Сначала он проверяет соответствие варианта. Затем оценивает свежесть. Свежий ответ можно вернуть без origin. Несвежий ответ не обязательно нужно загружать заново: кэш может отправить условный запрос с <code>If-None-Match</code>. Origin ответит <code>304 Not Modified</code>, если представление не изменилось, или <code>200</code> с новым телом, если изменилось.</p>\n<p><code>ETag</code> не очищает запись и не делает ответ свежим. Он позволяет сравнить сохранённое представление с текущим. <code>no-cache</code> тоже не означает «не хранить»: директива требует повторной проверки перед использованием. <code>no-store</code> запрещает хранение ответа в соответствии с правилами кэша. <code>private</code> ограничивает использование частным кэшем и подходит для ответа, который нельзя отдавать общему кэшу.</p>\n<p>У ответа может быть несколько точек наблюдения: приложение, reverse proxy, CDN и браузер. Заголовок, снятый на origin, не доказывает, что тот же заголовок дошёл до браузера. Посредник может изменить TTL, ключ или правило обхода. Поэтому проверка должна сравнивать один сценарий на каждой доступной границе.</p>\n<h2>Учебный пример: два варианта одного URL</h2>\n<p>Ниже приведены команды для безопасного тестового домена. Это учебный сценарий, а не результат измерения production. Он меняет только один вход — язык — и сохраняет тело и заголовки отдельно. В реальной команде замените адрес на тестовый URL без личных данных.</p>\n<pre><code># Запросы к 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: &quot;catalog-ru-v18&quot;' \\\n  https://origin.example.test/catalog</code></pre>\n<p>Если тела различаются по языку, в ответе ожидается <code>Vary: Accept-Language</code> либо эквивалентное явно настроенное правило cache key. Если origin возвращает один язык для обоих запросов, CDN пока не проверяем: источник уже нарушает ожидаемый контракт. Если origin корректен, а публичный адрес склеивает ответы, ищем расхождение в CDN или reverse proxy.</p>\n<p>Значение <code>ETag</code> в команде условное. Его нужно взять из предыдущего ответа для того же языка. Нельзя использовать русский валидатор для английского варианта. При неизменном русском представлении ожидаем <code>304</code> после повторной проверки. После изменения русского HTML ожидаем новый <code>200</code> и новый валидатор. Конкретный статус и заголовки нужно подтвердить на вашем стенде.</p>\n<h2>Симптомы и действия</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика HTTP-кэша по наблюдаемому симптому</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>После релиза старый JavaScript</td><td>Постоянный URL и длинный TTL</td><td>Сравнить URL из нового HTML и digest файла</td><td>Добавить fingerprint или сократить контракт свежести</td></tr><tr><td>Английский запрос получает русский HTML</td><td>Язык не входит в вариант кэша</td><td>Сделать два запроса с разным <code>Accept-Language</code> и сравнить <code>Vary</code></td><td>Исправить ключ варианта или отказаться от общего кэша</td></tr><tr><td>Всегда приходит полный ответ после истечения TTL</td><td>Нет валидатора или условный запрос не доходит до origin</td><td>Повторить запрос с прежним <code>ETag</code> и проверить путь через proxy</td><td>Настроить устойчивый валидатор и проверить каждый слой</td></tr><tr><td>Публичный ответ отличается от origin</td><td>CDN переписывает заголовки или использует другой ключ</td><td>Снять одинаковые заголовки через origin и публичный адрес</td><td>Сверить правило CDN с HTTP-контрактом origin</td></tr><tr><td>Данные одного пользователя видит другой</td><td>Персональный ответ попал в общий кэш</td><td>Проверить <code>Cookie</code>, авторизацию и <code>Cache-Control</code> на тестовых сессиях</td><td>Выбрать <code>private</code>, <code>no-store</code> или разделить публичную и личную части</td></tr></tbody></table></div>\n<h2>Иллюстрация ключа и свежести</h2>\n<figure><img src=\"/assets/editorial/2019/http-cache-key-2019.svg\" alt=\"Схема выбора HTTP-кэша: URL и Vary формируют ключ варианта, затем кэш проверяет свежесть; после истечения срока условный запрос с ETag приводит к 304 или к новому 200\" loading=\"lazy\" /><figcaption>Кэш сначала выбирает подходящее представление, затем проверяет его свежесть. Только после этого срабатывает повторная проверка через валидатор.</figcaption></figure>\n<h2>Порядок проверки</h2>\n<ol><li>Выберите один тестовый URL и запишите допустимую давность ответа. Для цены, HTML, asset и личных данных это могут быть разные правила.</li><li>Выпишите все входы, которые меняют тело: query, язык, кодирование, cookie, авторизацию, эксперимент или географию.</li><li>Снимите ответ origin и публичный ответ одним методом. Сохраните статус, тело или его digest, <code>Cache-Control</code>, <code>ETag</code>, <code>Vary</code> и <code>Age</code>, если поле есть.</li><li>Проверьте два безопасных варианта, меняя только один вход. Разные тела требуют разных вариантов; одинаковые тела не требуют добавлять <code>Vary</code> по предположению.</li><li>Дождитесь истечения выбранного срока на тестовом стенде или используйте короткий TTL. Повторите запрос с прежним <code>ETag</code> и зафиксируйте ожидаемый <code>304</code> либо новый <code>200</code>.</li><li>После изменения правила повторите тот же сценарий через origin, proxy, CDN и браузер, если эти границы доступны. Не очищайте кэш до первого снимка: иначе исчезнет доказательство исходного поведения.</li><li>Проверьте отрицательный путь: персональный ответ, неизвестный язык, изменение asset и запрос без валидатора. Для каждого случая заранее запишите безопасный результат.</li></ol>\n<h2>Ограничения</h2>\n<p>Эта модель объясняет HTTP-контракт, но не знает настройки конкретного CDN. Поставщик может иметь собственный cache key, отдельный TTL и правила обхода. Браузер может показать результат навигационной истории или service worker, а не обычного HTTP-кэша. Заголовок <code>Age</code> может отсутствовать и не доказывает отсутствие хранения. Поэтому один ответ <code>curl</code> не описывает весь маршрут пользователя.</p>\n<p><code>Vary</code> не заменяет явную проверку персонализации. Если тело зависит от cookie, эксперимента или пользователя, перечисление большого набора полей дробит кэш и может оставить риск утечки. Для личного HTML чаще безопаснее не использовать общий кэш. Для публичной локализации нужен ограниченный список вариантов и тест на каждый поддерживаемый язык.</p>\n<p>Учебный пример не обещает конкретное ускорение и не доказывает работу вашей инфраструктуры. Проверяемый результат должен появиться только после запуска команд на контролируемом домене и сравнения ответов. Не публикуйте в диагностике токены, cookie, персональные query-параметры и внутренние адреса.</p>\n<h2>Критерий готовности</h2>\n<p>Работу можно считать завершённой, когда для каждого выбранного URL есть короткая карточка: входы, допустимая давность, ожидаемые директивы, валидатор и граница, на которой это проверяется. Два запроса с разными входами не смешивают тела. После истечения срока неизменённое представление даёт ожидаемую условную проверку, а изменённое — новый ответ. Новый asset получает новый URL. Персональный ответ не попадает в общий кэш. Если хотя бы один пункт нельзя показать заголовками и телом ответа, контракт ещё не доказан.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://www.rfc-editor.org/rfc/rfc9111.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 9111: HTTP Caching</a> — актуальный стандарт для хранения, свежести, повторной проверки и директив управления кэшем.</li><li><a href=\"https://www.rfc-editor.org/rfc/rfc9110.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 9110: HTTP Semantics</a> — семантика представлений, валидаторов, <code>ETag</code>, <code>Vary</code> и условных ответов.</li><li><a href=\"https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching\" target=\"_blank\" rel=\"noopener noreferrer\">MDN: HTTP caching</a> — официальное практическое объяснение свежести, валидаторов и различий между <code>no-cache</code> и <code>no-store</code>.</li></ul>"
+  "title": "HTTP-кэш: почему правильный TTL не спасает ответ",
+  "excerpt": "Кэш проверяет не только срок свежести. Разбираем cache key, Vary, ETag и границы браузера, proxy и CDN на воспроизводимом сценарии.",
+  "contentHtml": "<p>После релиза пользователь открывает знакомый адрес и видит старый JavaScript или HTML не на том языке. В ответе есть <code>Cache-Control: max-age=60</code>, поэтому команда ждёт обновления через минуту. Но один клиент получает новый файл, другой — старый, а CDN продолжает отвечать из своей записи. Цена ошибки — неверное состояние страницы, лишняя нагрузка на origin и попытки очищать кэш вслепую.</p>\n<p>Причина часто не в числе 60. Кэш сначала решает, подходит ли сохранённый ответ этому запросу, и только потом проверяет его свежесть. Если ключ варианта неполон, свежий ответ всё равно будет неправильным. Если ключ верен, но ответ устарел, помогает валидатор вроде <code>ETag</code>. Эти две задачи нельзя заменять одним большим TTL.</p>\n<h2>Модель: ключ, свежесть и проверка</h2>\n<p>В HTTP cache key как минимум включает метод и target URI запроса. Для обычных GET-кэшей на практике главным компонентом остаётся URI. Но origin может выбирать представление по заголовкам запроса, например по <code>Accept-Language</code> или <code>Accept-Encoding</code>. Тогда ответ должен сообщить об этом через <code>Vary</code>: кэш сравнивает названные поля текущего запроса с полями запроса, который породил сохранённый ответ.</p>\n<p>Управляемый CDN может добавить к ключу собственные признаки: cookies, географию, эксперимент или правило из панели. Это не отменяет HTTP-контракт. Заголовок, снятый на origin, не доказывает поведение публичного адреса: proxy или CDN может выбрать другую запись, изменить свежесть или отправить запрос дальше. Название настройки вроде «cache key» тоже не доказывает, какие поля реально участвуют в выборе.</p>\n<p><code>max-age</code> задаёт срок, после которого ответ считают несвежим. Это не срок жизни записи и не команда удалить её. Несвежая запись может быть повторно проверена у origin. При совпавшем валидаторе origin для GET или HEAD обычно возвращает <code>304 Not Modified</code> без нового тела; при изменении представления — <code>200</code> с новым телом и новым валидатором.</p>\n<h2>Что именно делают директивы</h2>\n<p><code>ETag</code> сравнивает сохранённое представление с текущим. Он не очищает запись и сам по себе не делает её свежей. <code>no-cache</code> в ответе тоже не означает «не хранить»: перед повторным использованием кэш должен обратиться к origin для успешной проверки. <code>no-store</code> запрещает кэшу намеренно хранить ответ и использовать его для другого запроса, но не является полноценной защитой от скомпрометированного посредника.</p>\n<p><code>private</code> запрещает хранение ответа в shared cache, но разрешает private cache пользователя при остальных условиях. Это подходит для персонализированного ответа, если его всё равно допустимо хранить в браузере. Для личного HTML часто безопаснее выбрать <code>no-store</code>. Для shared cache отдельный <code>s-maxage</code> задаёт максимальный возраст и переопределяет <code>max-age</code> для общего кэша; после истечения срок всё равно требует корректного правила повторной проверки.</p>\n<p>Из этого следует порядок решения: сначала совпадение URI, метода и варианта; затем допустимость повторного использования; затем свежесть; затем, если нужно, условный запрос к origin. Нельзя выводить причину по одному заголовку. <code>Age</code> полезен как признак того, что ответ был сгенерирован или проверен не для этого запроса, но отсутствие <code>Age</code> не доказывает обращение к origin.</p>\n<h2>Учебный пример: язык меняет ответ</h2>\n<p>Ниже приведён учебный сценарий для контролируемого домена. Он меняет только <code>Accept-Language</code>, сохраняет заголовки и тело отдельно и не выдаёт результат за измерение production. Подставьте URL тестового origin и не используйте в команде настоящие cookies или токены.</p>\n<pre><code># 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: &quot;catalog-ru-v18&quot;' https://origin.example.test/catalog</code></pre>\n<p>Если origin действительно выбирает HTML по языку, для общего HTTP-кэша ожидается <code>Vary: Accept-Language</code>. Отдельное vendor-specific правило cache key может быть нужно CDN, но оно не заменяет заголовок для других посредников. Если origin отдал одинаковые тела, сначала исправьте выбор представления у источника: проверка CDN только замаскирует проблему.</p>\n<p>Значение <code>ETag</code> в команде условное. В рабочем запуске его нужно скопировать из предыдущего ответа для русского варианта, сохранив кавычки. Нельзя использовать русский валидатор для английского. Если представление не менялось и запрос дошёл до origin, ожидаем <code>304</code>; при изменении тела ожидаем новый <code>200</code>. Статус нужно зафиксировать на вашем стенде, а не обещать заранее.</p>\n<h2>Симптомы и действия</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика HTTP-кэша по наблюдаемому симптому</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Гипотеза</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>После релиза старый JavaScript</td><td>Постоянный URL и длинный TTL</td><td>Сравнить URL из нового HTML и digest файла</td><td>Добавить fingerprint или изменить контракт свежести</td></tr><tr><td>Английский запрос получает русский HTML</td><td>Нет <code>Vary</code> или CDN не учитывает вариант</td><td>Сделать два запроса, сравнить тела и заголовки на origin и public URL</td><td>Согласовать выбор представления, <code>Vary</code> и cache key</td></tr><tr><td>После TTL всегда приходит полный ответ</td><td>Нет валидатора или условный запрос не доходит до origin</td><td>Повторить запрос с прежним <code>ETag</code> и проверить маршрут</td><td>Настроить устойчивый валидатор и проверить каждый слой</td></tr><tr><td>Публичный ответ отличается от origin</td><td>Proxy или CDN меняет ключ, TTL или заголовки</td><td>Снять одинаковые поля и digest через обе точки</td><td>Сверить конфигурацию посредника с HTTP-контрактом</td></tr><tr><td>Данные одного пользователя видит другой</td><td>Персональный ответ попал в shared cache</td><td>Проверить две тестовые сессии, <code>Authorization</code>, cookies и директивы</td><td>Выбрать <code>private</code>, <code>no-store</code> или разделить публичную и личную части</td></tr><tr><td>CDN обслуживает запись дольше браузера</td><td>Используется <code>s-maxage</code>, отличный от <code>max-age</code></td><td>Сравнить <code>Age</code>, <code>Cache-Control</code> и vendor headers</td><td>Зафиксировать отдельную политику shared cache и критерий purge</td></tr></tbody></table></div>\n<h2>Иллюстрация ключа и свежести</h2>\n<figure><img src=\"/assets/editorial/2019/http-cache-key-2019.svg\" alt=\"Схема выбора HTTP-кэша: метод и URL задают базовый ключ, Vary добавляет поля запроса, затем кэш проверяет свежесть и при необходимости валидирует ETag у origin\" loading=\"lazy\" /><figcaption>Кэш сначала выбирает подходящее представление по ключу, затем проверяет свежесть. Только после этого для несвежего ответа начинается повторная проверка через валидатор.</figcaption></figure>\n<h2>Порядок проверки</h2>\n<ol><li>Выберите один тестовый URL и опишите, какой ответ считается публичным, а какой персональным. Для HTML, asset и API правила могут различаться.</li><li>Запишите метод и все входы, которые могут менять тело: query, язык, кодирование, cookie, авторизацию, эксперимент или географию. Отдельно отметьте, какие из них реально входят в cache key.</li><li>Снимите ответ origin и публичный ответ одним методом. Сохраните статус, digest тела, <code>Cache-Control</code>, <code>ETag</code>, <code>Vary</code>, <code>Age</code> и <code>Date</code>, если поля есть.</li><li>Проверьте два варианта, меняя только один вход. Если тела различаются, найдите правило, которое разделяет их; если одинаковы, не добавляйте <code>Vary</code> по предположению.</li><li>Сопоставьте <code>max-age</code> и, если он используется, <code>s-maxage</code>. Не называйте истечение TTL удалением записи: оно может привести к условному запросу, а не к загрузке нового тела.</li><li>Повторите запрос после истечения срока с валидатором именно того варианта. Зафиксируйте <code>304</code>, новый <code>200</code> или иной фактический ответ и объясните его по заголовкам.</li><li>Сравните origin, reverse proxy, CDN и браузер, если эти границы доступны. Для браузера отдельно исключите service worker и историю навигации. Не очищайте кэш до первого снимка.</li><li>Проверьте отрицательный путь: персональный ответ, неизвестный язык, изменение asset и запрос без валидатора. Для каждого заранее запишите безопасный ожидаемый результат.</li></ol>\n<h2>Ограничения</h2>\n<p>HTTP задаёт правила кэша, но не описывает конфигурацию каждого CDN. Посредник может иметь отдельный cache key, TTL, stale policy и операцию purge. Браузер может показать данные из service worker или навигационной истории, а не из обычного HTTP-кэша. Поэтому один ответ <code>curl</code> не описывает весь путь пользователя.</p>\n<p><code>Vary</code> не заменяет проверку персонализации. Если тело зависит от cookie, эксперимента или пользователя, попытка перечислить все поля дробит кэш и может оставить риск утечки. Для личного HTML безопаснее начать с <code>private</code> или <code>no-store</code>, а публичную локализацию ограничить известным списком вариантов.</p>\n<p>Учебный домен, хэш файла и значение <code>ETag</code> не являются результатами измерения. Стандарт не гарантирует конкретный hit ratio, ускорение или поведение vendor-specific purge. В диагностике нельзя публиковать токены, cookies, персональные query-параметры и внутренние адреса.</p>\n<h2>Критерий готовности</h2>\n<p>Проверку можно считать завершённой, когда для выбранного URL записаны входы, допустимая давность, владелец правила cache key, ожидаемые директивы, валидатор и граница, на которой каждый пункт проверяется. Два запроса с разными входами не смешивают тела. После истечения срока неизменённое представление даёт подтверждённую условную проверку, а изменённое — новый ответ. Новый asset получает новый URL. Персональный ответ не попадает в shared cache.</p>\n<p>Если это нельзя показать заголовками, телом и снимками на доступных границах, контракт ещё не доказан. Исправление начинается с уровня, где появилось расхождение: origin, proxy, CDN или браузер. Очистка кэша может убрать симптом, но не доказывает, что ключ и срок теперь согласованы.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://www.rfc-editor.org/rfc/rfc9111.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 9111: HTTP Caching</a> — стандарт для cache key, <code>Vary</code>, свежести, валидации, <code>Age</code> и директив <code>Cache-Control</code>.</li><li><a href=\"https://www.rfc-editor.org/rfc/rfc9110.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 9110: HTTP Semantics</a> — семантика представлений, валидаторов, <code>ETag</code>, <code>Vary</code> и условных ответов.</li><li><a href=\"https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching\" target=\"_blank\" rel=\"noopener noreferrer\">MDN: HTTP caching</a> — практическое объяснение private/shared cache, <code>no-cache</code>, <code>no-store</code>, proxy и managed cache.</li></ul>"
 }