Internet Engineering Task Force (IETF) M. Nottingham Request for Comments: 9875 Cloudflare Category: Standards Track October 2025 ISSN: 2070-1721
HTTP Cache Groups
Группы кэша HTTP
Аннотация
Эта спецификация вводит понятия для описания связей между сохранёнными в кэшах HTTP откликами, группируя их путём сопоставления с одной или несколькими строками.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительные сведения о документах Internet Standard приведены в разделе 2 RFC 7841.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9875.
Авторские права
Авторские права (Copyright (c) 2025) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с пересмотренной лицензией BSD (Revised BSD License), как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Revised BSD License).
1. Введение
Кэширование HTTP [HTTP-CACHING] работает на уровне одного ресурса и свежесть одного сохранённого отклика не влияет на свежесть других. Такая гранулярность может повысить эффективность кэширования, например, в случае включения в страницу нескольких ресурсов с разными требованиями к кэшированию.
Однако в некоторых случаях связи между сохранёнными откликами могут повышать эффективность кэширования. Например, часто возникает необходимость аннулировать (invalidate) набор связанных ресурсов. Это может быть связано с побочным влиянием запроса на изменение состояния на другие ресурсы или задано для удобства администрирования (например, аннулировать некую часть сайта). Группировка ресурсов обеспечивает способ выразить такие взаимосвязи вместо того, чтобы полагаться на такие вещи, как структура URL.
В дополнение в обобществлению событий аннулирования установленные при группировке связи могут использоваться кэшами для оптимизации работы (например, для информирования о работе алгоритмов вытеснения из кэша).
В разделе 2 представлены способы описания взаимосвязей между откликами, сохранёнными в кэшах HTTP, путём включения этих откликов в одну или несколько групп, отражающих эти взаимоотношения. Описано также использование этих связей кэшами для применения операций аннулирования к членам группы.
В разделе 3 представлен один новый источник таких событий — поле заголовка отклика HTTP, которое позволяет меняющему состояние отклику запустить аннулирование группы.
Эти механизмы работают в рамках одного кэша с сохранёнными откликами, связанными с одним сервером-источником (см. параграф 2.1). Они не решают задачу синхронизации состояний между разными кэшами (например, в иерархии или многосвязной сети) и не способствуют связыванию сохранённых откликов от разных источников.
1.1. Уровни требований и терминология
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
В спецификации применяются термины, определённые в [STRUCTURED-FIELDS]: List, String, Parameter.
2. Поле Cache-Groups в заголовке отклика
Поле Cache-Groups в заголовке отклика содержит список строк (List of Strings, параграфы 3.1 и 3.3.3 в [STRUCTURED-FIELDS]). Каждый элемент списка является значением, идентифицирующим группу, к которой отклик относится. Строки «непрозрачны» (opaque) и не имеют никакого смысла для создавшего их сервера, кэш не знает их структуру и содержимое, кроме однозначной идентификации группы.
HTTP/1.1 200 OK Content-Type: application/javascript Cache-Control: max-age=3600 Cache-Groups: "scripts"
Порядок элементов не имеет значения, нераспознанные параметры игнорируются.
Реализации должны поддерживать в значении поля не менее 32 групп, каждая из которых содержит не менее 32 символов. Отметим, что на размер полей могут влиять базовые ограничения HTTP.
2.1. Идентификация сгруппированных откликов
Два отклика, хранящиеся в одном кэше, считаются относящимися к одной группе при выполнении двух условий:
-
оба отклика включают поле заголовка Cache-Groups с одинаковым значением (в любой позиции списка) при посимвольном сравнении с учётом регистра;
-
в обоих откликах совпадают URI источника (параграф 4.3.1 в [HTTP]).
2.2. Поведение кэша
2.2.1. Аннулирование
Аннулирующий сохранённый отклик кэш может аннулировать любые сохранённые отклики той же группы (параграф 2.1. Отметим, что групповое аннулирование не вызывает группового аннулирования, т. е. механизм не каскадируется.
Расширения кэша могут усиливать это требование. Например, поле заголовка управления целевым кэшем [TARGETED] может указывать на то, что при обработке кэшей следует аннулировать такие отклики.
3. Поле Cache-Group-Invalidation в заголовке отклика
Поле Cache-Group-Invalidation в заголовке отклика является списком строк (параграфы 3.1 и 3.3.3 в [STRUCTURED-FIELDS]). Каждый элемент списка является значением, указывающим группу, отклики из которой аннулируются в соответствии с параграфом 2.2.1.
Например, приведённый ниже запрос POST оказывает воздействие на две группы кэша и соответствующий отклик может указывать, что связанные с одной или обеими группами отклики следует аннулировать
HTTP/1.1 200 OK Content-Type: text/html Cache-Group-Invalidation: "eurovision-results", "australia"
Поле Cache-Group-Invalidation должно игнорироваться в откликах на запросы, использующие безопасный метод (например, GET, см. параграф 9.2.1 в [HTTP]).
Кэш, получивший отклик на небезопасный запрос с полем Cache-Group-Invalidation в заголовке, может аннулировать любые сохранённые отклики той же группы (параграф 2.1) для любой из указанных в списке групп.
Расширения кэша могут усиливать это требование. Например, поле заголовка управления целевым кэшем [TARGETED] может указывать, что обрабатывающие его кэши должны учитывать сигнал Cache-Group-Invalidation.
Порядок указания в списке не имеет значения. Нераспознанные параметры игнорируются.
Реализации должны поддерживать в значении поля не менее 32 групп, каждая из которых содержит не менее 32 символов. Отметим, что на размер полей могут влиять базовые ограничения HTTP.
4. Взаимодействие с IANA
Агентство IANA добавило в реестр Hypertext Transfer Protocol (HTTP) Field Name Registry приведённые ниже сведения.
Field Name: Cache-Groups Status: permanent Reference: RFC 9875 Field Name: Cache-Group-Invalidation Status: permanent Reference: RFC 9875
5. Вопросы безопасности
Описанный механизм позволяет ресурсам с одним источником аннулировать друг друга. По этой причине источники, представляющие несколько сторон (иногда это называют «общим хостингом»), могут позволить одной стороне группировать свои ресурсы с другими или передавать сигналы, которые будут иметь побочные эффекты для них.
Совместно используемые хосты могут смягчить эти риски путём контроля доступа к описанным здесь полям заголовков.
6. Литература
6.1. Нормативные документы
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., «HTTP Semantics», STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
[HTTP-CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., «HTTP Caching», STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/info/rfc9111>.
[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[STRUCTURED-FIELDS] Nottingham, M. and P. Kamp, «Structured Field Values for HTTP», RFC 9651, DOI 10.17487/RFC9651, September 2024, <https://www.rfc-editor.org/info/rfc9651>.
6.2. Дополнительная литература
[TARGETED] Ludin, S., Nottingham, M., and Y. Wu, «Targeted HTTP Cache Control», RFC 9213, DOI 10.17487/RFC9213, June 2022, <https://www.rfc-editor.org/info/rfc9213>.
Благодарности
Спасибо Stephen Ludin за рецензию и предложения.
Адрес автора
Mark Nottingham
Cloudflare
Melbourne
Australia
Email: mnot@mnot.net
Перевод на русский язык
Николай Малых
1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.