Кэширование HTTP-представлений¶
Требования применяются к динамическим HTTP-представлениям, кэшируемым browser,
reverse proxy, Content Delivery Network (CDN) или иным shared cache.
Хешированные статические ресурсы регулируются FE-BUILD-004. Уровни
обязательности определены в корневом README.md.
Private cache хранит представление для одного пользовательского контекста; shared cache может повторно использовать ответ между независимыми запросами.
INT-CACHE-001. Явная политика кэширования¶
Уровень: MUST
Применяется к: динамическому HTTP-представлению, которое browser, reverse proxy или shared cache может сохранить
Контракт должен явно разрешать либо запрещать хранение. При разрешении он должен
определять кэшируемые методы и статусы, private или shared область,
максимальный срок свежести, необходимость revalidation и допустимость stale-
ответа. Ответ должен передавать согласованные Cache-Control и связанные
headers; отсутствие директивы не должно использоваться как единственное
объявление политики.
Ответ с персональными, авторизационно ограниченными или tenant-specific данными
не должен становиться shared cache entry без явно проверяемой изоляции по
INT-CACHE-002. Ответ, который запрещено сохранять, должен объявлять это
явной директивой.
Обоснование¶
Неявная эвристика cache способна сохранить защищённый ответ или показывать динамические данные дольше продуктового контракта.
Проверка¶
- contract-тест headers каждого класса ответа;
- тест private, shared и запрещённого кэширования;
- проверка поведения browser и фактической shared cache.
Исключения¶
Ответ, который ни один участник не сохраняет и который явно помечен запрещающей директивой, не требует срока свежести.
INT-CACHE-002. Cache key и разграничение доступа¶
Уровень: MUST
Применяется к: представлению в shared cache
Cache key должен включать host, нормализованные path и перечисленные контрактом
query-компоненты, а также каждый вход, меняющий bytes, локаль, encoding, tenant
или полномочия ответа. Влияющие request headers должны быть согласованы с
Vary либо эквивалентной проверяемой конфигурацией cache. Необъявленный
query-параметр не должен незаметно создавать другой защищённый вариант.
Запрос не должен получать entry, созданный для другого субъекта, tenant,
состояния аутентификации или набора прав. Изменение прав и выход должны
выполнять FE-API-008; cache key, контролируемый недоверенным клиентом, не
должен считаться доказательством авторизации.
Обоснование¶
Одинаковый URL не означает одинаковое представление для разных локалей, encoding и контекстов доступа.
Проверка¶
- параллельный тест разных субъектов, tenant, locale и encoding;
- review фактической конфигурации cache key и
Vary; - негативный тест подмены query, cookie и forwarded identity.
Исключения¶
Доказуемо публичное представление MAY иметь общий ключ без субъекта и tenant.
INT-CACHE-003. Freshness, revalidation и invalidation¶
Уровень: MUST
Применяется к: изменяемому кэшируемому представлению
Проект должен определить максимальную давность, событие invalidation и
поведение при недоступности origin. Если используются ETag,
Last-Modified или иные validators, один validator должен обозначать одну
версию представления; ответ 304 Not Modified не должен менять её bytes и
должен сохранять согласованные metadata.
Подтверждённое изменение или удаление должно инвалидировать entry либо становиться видимым не позднее объявленной максимальной давности. Разрешённые stale-режимы должны иметь конечные сроки и не должны использоваться для просроченного состояния прав. Ошибка обновления не должна заменять пригодный entry частичным или невалидным ответом.
Обоснование¶
Validator без стабильной версии и неограниченный stale-режим делают актуальность ответа неопределённой и сохраняют отозванный доступ.
Проверка¶
- contract-тест conditional request и
304; - тест изменения, удаления, invalidation и истечения максимальной давности;
- тест недоступного origin и просроченного состояния прав.
Исключения¶
Неизменяемое представление с content-addressed URL не требует invalidation, если изменение всегда создаёт новый URL.