Кеширование
Cache-Control: спроектируй и проверь политику кэширования
Читать директивы — не то же, что отправить политику, которая держится под CDN. Собери небольшое приложение с четырьмя каноническими формами маршрутов — персональный HTML, хешированные статические ассеты, кэшируемый публичный API, чувствительный эндпоинт — дай каждому верный Cache-Control, затем докажи на проводе, в том числе спровоцировав утечку из-за отсутствия private и наблюдая, как она исчезает после исправления.
Преврати дерево решений юнита в проверенную политику кэширования по маршрутам: выбирай директивы по нуждам разделения и свежести, наблюдай, что реально делают браузер и CDN через cache-status и заголовки Age, и продемонстрируй и сбой, и исправление с захваченными доказательствами.
Собери (или возьми) небольшое приложение, отдаваемое через реальный CDN или локальный прокси общего кэша, спроектируй политику Cache-Control по маршрутам для четырёх форм маршрутов и докажи наблюдаемыми заголовками, что персональные данные никогда не утекают в общий кэш, статические ассеты корректно кэшируются на год, а публичный API отдаёт устаревшее-но-быстрое под stale-while-revalidate.
- Таблица политики, сопоставляющая каждый из четырёх маршрутов с его заголовком Cache-Control и обоснованием хранения/переиспользования, совпадающая с тем, что реально отправляют живые ответы.
- Захваченные заголовки ответа (или строки cache-status), доказывающие: дашборд никогда не в общем кэше, бандл отдаётся immutable и не ревалидируется при перезагрузке, а публичный API возвращает устаревший HIT под stale-while-revalidate с Age за s-maxage.
- Захват до/после утечки из-за private: пользователь B получает дашборд пользователя A под public, затем чистый перезапрос на пользователя после возврата private, no-store.
- Однопараграфное описание, объясняющее, почему выбрана директива каждого маршрута и какой конкретный инцидент она предотвращает (утечка bfcache, отравление CDN, удар по origin, устаревший на год ассет).
- Добавь эксперимент с Vary: поставь Vary: Cookie на почти-персональный маршрут, замерь обвал hit-rate из-за фрагментации кэша и подтверди, соблюдает ли твой CDN Vary вообще — затем обоснуй, почему безопасность должна нести private/no-store, а не Vary.
- Добавь stale-if-error к публичному API, положи origin и покажи, как CDN отдаёт устаревшее вместо ошибки в настроенном окне.
- Добавь CI-проверку, проваливающую сборку, если любой аутентифицированный маршрут отправляет заголовок без private или no-store, сканируя таблицу маршрутов или захваченный снимок заголовков.
- Повтори замер публичного API на втором CDN/прокси и сравни, как каждый интерпретирует s-maxage, stale-while-revalidate и Vary — задокументировав любые вендор-специфичные отклонения.
Это цикл, который ты запустишь для каждого маршрута в реальной системе: сначала задай два вопроса — может ли кэш хранить это и может ли переиспользовать сохранённую копию без ревалидации — затем выбирай директивы по разделению и свежести, считая, что впереди стоит CDN, видишь ты его или нет. no-store для чувствительных данных, private для данных на пользователя, public + immutable + год для ассетов с хешем содержимого, а max-age/s-maxage/stale-while-revalidate настроены по уровням для публичного API. Затем докажи на проводе: наблюдай заголовки cache-status и Age, намеренно спровоцируй утечку из-за private и наблюдай, как она исчезает, когда директива верна. Сделав это раз на игрушечном приложении, ты доведёшь ревью production-политики до автоматизма.