RFC 7234 | Протокол передачи гипертекста (HTTP/1.1): кэширование

RFC 7234 | Протокол передачи гипертекста (HTTP/1.1): кэширование

Аннотация

Протокол передачи гипертекста (HTTP) — это протокол уровня приложений без сохранения состояния для распределенных, совместных гипертекстовых информационных систем. Этот документ определяет HTTP-кеши и связанные поля заголовков, которые управляют поведением кеша или указывают кешируемые ответные сообщения.

Скачать оригинальную версию документа на английском языке RFC 7234 PDF

 

Оглавление

1. Введение
1.1. Соответствие и обработка ошибок
1.2. Синтаксическая нотация
1.2.1. Правило Дельта Секунд
2. Обзор работы кэша
3. Хранение ответов в кеше
3.1. Хранение неполных ответов
3.2. Хранение ответов на аутентифицированные запросы
3.3. Объединение Частичного Содержимого
4. Построение ответов из кешей
4.1. Вычисление вторичных ключей с помощью Vary
4.2. Свежесть
4.2.1. Расчет свежести жизни
4.2.2. Расчет эвристической свежести
4.2.3. Расчет возраста
4.2.3.1. age_value
4.2.3.2. date_value
4.2.3.3. now
4.2.3.4. request_time
4.2.3.5. response_time
4.2.4. Обслуживание устаревших ответов
4.3. Проверка
4.3.1. Отправка запроса на проверку
4.3.2. Обработка полученного запроса на проверку
4.3.3. Обработка ответа на валидацию
4.3.4. Обновление сохраненных ответов при проверке
4.3.5. Освежение ответов через метод HEAD
4.4. Невалидность (Признание недействительным)
5. Определения полей заголовка
5.1. Заголовок Age
5.2. Заголовок Cache-Control
5.2.1. Директивы запроса Cache-Control
5.2.1.1. max-age
5.2.1.2. max-stale
5.2.1.3. min-fresh
5.2.1.4. no-cache
5.2.1.5. no-store
5.2.1.6. no-transform
5.2.1.7. only-if-cached
5.2.2. Директивы ответа Cache-Control
5.2.2.1. must-revalidate
5.2.2.2. no-cache
5.2.2.3. no-store
5.2.2.4. no-transform
5.2.2.5. public
5.2.2.6. private
5.2.2.7. proxy-revalidate
5.2.2.8. max-age
5.2.2.9. s-maxage
5.2.3. Расширения контроля кэша
5.3. Заголовок Expires
5.4. Заголовок Pragma
5.5. Заголовок Warning
5.5.1. Предупреждение: 110 — «Ответ устарел»
5.5.2. Предупреждение: 111 — «Сбой повторной проверки»
5.5.3. Предупреждение: 112 — «Отключенная операция»
5.5.4. Предупреждение: 113 — «Эвристическое истечение срока»
5.5.5. Предупреждение: 199 — «Разное предупреждение»
5.5.6. Предупреждение: 214 — «Преобразование применено»
5.5.7. Предупреждение: 299 — «Разное постоянное предупреждение»
6. Списки истории
7. Соображения IANA
7.1. Реестр кеша
7.1.1. Процедура
7.1.2. Соображения по поводу новых директив управления кэшем
7.1.3. Регистрации
7.2. Реестр кодов предупреждений
7.2.1. Процедура
7.2.2. Регистрации
7.3. Регистрация поля заголовка
8. Вопросы безопасности
9. Благодарности
10. Ссылки
10.1. Нормативные ссылки
10.2. Информационные ссылки
Приложение A. Изменения по сравнению с RFC 2616
Приложение B. Импортированный ABNF
Приложение C. Собранный ABNF
Индекс
Адреса авторов

 

1. Введение

HTTP обычно используется для распределенных информационных систем, где производительность можно улучшить с помощью кэшей ответов. Этот документ определяет аспекты HTTP/1.1, связанные с кэшированием и повторным использованием ответных сообщений.

HTTP-кеш — это локальное хранилище ответных сообщений и подсистема, которая управляет хранением, поиском и удалением сообщений в нем. Кэш хранит кешируемые ответы, чтобы уменьшить время ответа и потребление пропускной способности сети при будущих эквивалентных запросах. Любой клиент или сервер МОЖЕТ использовать кеш, хотя кеш не может использоваться сервером, который действует как туннель.

Общий кэш — это кэш, в котором хранятся ответы, которые могут быть использованы более чем одним пользователем; общие кэши обычно (но не всегда) развертываются как часть посредника. Частный кеш, напротив, предназначен для одного пользователя; часто они развертываются как компонент пользовательского агента.

Целью кэширования в HTTP/1.1 является значительное повышение производительности путем повторного использования предыдущего ответного сообщения для удовлетворения текущего запроса. Сохраненный ответ считается «fresh» (свежим), как определено в разделе 4.2, если ответ может быть повторно использован без «validation» (проверки) (проверка с помощью сервера-источника, чтобы убедиться, что кэшированный ответ остается действительным для этого запроса). Поэтому новый ответ может уменьшить как задержку, так и нагрузку на сеть при каждом повторном использовании. Когда кэшированный ответ не является свежим, он все еще может быть повторно использован, если его можно обновить путем проверки (раздел 4.3) или если источник недоступен (раздел 4.2.4).

1.1. Соответствие и обработка ошибок

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119 #] [RFC8174 #].

Критерии соответствия и соображения, касающиеся обработки ошибок, определены в разделе 2.5 [RFC7230 #].

1.2. Синтаксическая нотация

В этой спецификации используется нотация расширенной формы Бэкуса-Наура (ABNF) [RFC5234 #] с расширением списка, определенным в разделе 7 [RFC7230 #], который позволяет компактно определять списки, разделенные запятыми, используя оператор решётки «#» (аналогично как оператор звёздочки ‘*’ указывает на повторение). Приложение B описывает правила, импортированные из других документов. Приложение C показывает собранную грамматику со всеми операторами списка, расширенными до стандартной записи ABNF.

1.2.1. Правило Дельта Секунд

Правило дельта-секунд задает неотрицательное целое число, представляющее время в секундах.

delta-seconds = 1*DIGIT

Получатель, анализирующий значение в дельта-секундах и преобразующий его в двоичную форму, должен использовать арифметический тип по меньшей мере из 31 бита диапазона неотрицательных целых чисел. Если кэш получает значение в дельта-секундах, превышающее наибольшее целое число, которое он может представлять, или если любое из его последующих вычислений переполняется, кэш ДОЛЖЕН считать значение либо 2147483648 (231), либо наибольшим положительным целым числом, которое он может удобно представлять.

Примечание!

Значение 2147483648 приведено здесь по историческим причинам, фактически представляет бесконечность (более 68 лет) и не требует хранения в двоичной форме; Реализация может создать ее как постоянную строку, если произойдет какое-либо переполнение, даже если вычисления выполняются с арифметическим типом, неспособным непосредственно представлять это число. Здесь важно, чтобы переполнение было обнаружено и не рассматривалось как отрицательное значение в последующих вычислениях.

 

2. Обзор работы кэша

Правильная работа кеша сохраняет семантику HTTP-передач ([RFC7231 #]), исключая при этом передачу информации, уже находящейся в кеше. Хотя кэширование является полностью ДОПОЛНИТЕЛЬНОЙ функцией HTTP, можно предположить, что повторное использование кэшированного ответа желательно и что такое повторное использование является поведением по умолчанию, когда никакое требование или локальная конфигурация не препятствуют этому. Поэтому требования к HTTP-кэшу направлены на предотвращение хранения в кеше одноразового ответа или неправильного повторного использования сохраненного ответа, а не на обязательном хранении и повторном использовании определенных ответов в кэшах.

Каждая запись кэша состоит из ключа кэша и одного или нескольких HTTP-ответов, соответствующих предыдущим запросам, которые использовали один и тот же ключ. Наиболее распространенной формой записи в кэш является успешный результат запроса поиска: то есть ответ 200 (OK) на запрос GET, который содержит представление ресурса, идентифицированного целью запроса (раздел 4.3.1 [RFC7231 #] ). Однако также возможно кэшировать постоянные перенаправления, отрицательные результаты (например, 404 (не найдено)), неполные результаты (например, 206 (частичное содержимое)) и ответы на методы, отличные от GET, если определение метода допускает такое кэширование и определяет что-то подходящее для использования в качестве ключа кеша.

Основной ключ кеша состоит из метода запроса и целевого URI. Однако, поскольку широко используемые сегодня кэши HTTP обычно ограничиваются кэшированием ответов на GET, многие кэши просто отклоняют другие методы и используют только URI в качестве основного ключа кэша.

Если цель запроса является предметом согласования содержимого, ее запись в кэше может состоять из нескольких сохраненных ответов, каждый из которых дифференцируется вторичным ключом для значений полей заголовка выбора исходного запроса (раздел 4.1).

 

3. Хранение ответов в кеше

Кэш НЕ ДОЛЖЕН хранить ответ на любой запрос, если только:

  • Метод запроса понимается кешем и определяется как кешируемый, и
  • код состояния ответа понимается кешем, и
  • директива кэша «no-store» (см. раздел 5.2) не появляется в полях заголовка запроса или ответа, и
  • «private» директива ответа (см. раздел 5.2.2.6) не появляется в ответе, если кеш является общим, и
  • поле заголовка Authorization (см. раздел 4.2 в [RFC7235 #]) не появляется в запросе, если кеш является общим, если ответ явно не разрешает это (см. раздел 3.2), и
  • ответ либо:

* содержит поле заголовка Expires (см. раздел 5.3), или

* содержит директиву о максимальном возрасте (max-age) (см. раздел 5.2.2.8), или

* содержит директиву ответа s-maxage (см. раздел 5.2.2.9) и общий кэш, или

* содержит расширение управления кэшем (см. раздел 5.2.3), которое позволяет его кэшировать, или

* имеет код состояния, который по умолчанию определен как кешируемый (см. раздел 4.2.2), или

* содержит директиву о публичном ответе (public) (см. раздел 5.2.2.5).

Обратите внимание, что любое из перечисленных выше требований может быть отменено расширением управления кэшем (cache-control); см. раздел 5.2.3.

В этом контексте кэш «понял» (understood) метод запроса или код состояния ответа, если он распознает его и реализует все указанное поведение, связанное с кэшированием.

Обратите внимание, что при нормальной работе некоторые кэши не будут хранить ответ, который не имеет ни валидатора кэша, ни явного времени истечения, так как такие ответы обычно бесполезны для хранения. Однако кешам не запрещено хранить такие ответы.

 

3.1. Хранение неполных ответов

Ответное сообщение считается завершенным, если все октеты, указанные в кадре сообщения ([RFC7230 #]), получены до закрытия соединения. Если метод запроса — GET, код состояния ответа — 200 (ОК), и весь раздел заголовка ответа был получен, кэш МОЖЕТ хранить тело сообщения с неполным ответом, если запись в кэше записана как неполная. Аналогично, ответ 206 (частичное содержимое) МОЖЕТ быть сохранен, как если бы он был неполной 200 (ОК) записью в кэш. Однако кэш НЕ ДОЛЖЕН хранить неполные или частичные ответы контента, если он не поддерживает поля заголовка Range и Content-Range или если он не понимает единицы измерения диапазона, используемые в этих полях.

Кэш МОЖЕТ завершить сохраненный неполный ответ, сделав последующий запрос диапазона ([RFC7233 #]) и объединив успешный ответ с сохраненной записью, как определено в разделе 3.3. Кэш НЕ ДОЛЖЕН использовать неполный ответ для ответа на запросы, если ответ не был выполнен полным или запрос является частичным и указывает диапазон, который полностью находится в пределах неполного ответа. Кэш НЕ ДОЛЖЕН отправлять частичный ответ клиенту без явной пометки его как такового с использованием кода состояния 206 (частичное содержимое).

 

3.2. Хранение ответов на аутентифицированные запросы

Совместно используемый кеш НЕ ДОЛЖЕН использовать кэшированный ответ на запрос с полем заголовка Authorization (раздел 4.2 [RFC7235 #]), чтобы удовлетворить любой последующий запрос, если в ответе нет директивы кеша, которая позволяет хранить такие ответы.

В этой спецификации следующие директивы ответа Cache-Control (раздел 5.2.2) имеют такой эффект: must-revalidate, public и s-maxage.

Обратите внимание, что кэшированные ответы, содержащие директивы ответов «must-revalidate» и / или «s-maxage», не могут обслуживаться устаревшими (раздел 4.2.4) совместно используемыми кэшами. В частности, ответ с «max-age=0, must-revalidate» или «s-maxage=0» не может использоваться для удовлетворения последующего запроса без повторной проверки его на исходном сервере.

 

3.3. Объединение Частичного Содержимого

Ответ может передавать только частичное представление, если соединение преждевременно закрыто или если в запросе используется один или несколько спецификаторов Range ([RFC7233 #]). После нескольких таких передач кэш мог получить несколько диапазонов одного и того же представления. Кэш МОЖЕТ объединить эти диапазоны в один сохраненный ответ и повторно использовать этот ответ для удовлетворения более поздних запросов, если все они используют один и тот же строгий валидатор и кэш соответствует требованиям клиента в Разделе 4.3 [RFC7233 #].

При объединении нового ответа с одним или несколькими сохраненными ответами кэш ДОЛЖЕН:

  • удалить все поля заголовка Warning в сохраненном ответе с кодом предупреждения 1xx (см. раздел 5.5);
  • сохранить любые поля заголовка Warning в сохраненном ответе с кодом предупреждения 2xx; а также,
  • использовать другие поля заголовка, предоставленные в новом ответе, кроме Content-Range, чтобы заменить все экземпляры соответствующих полей заголовка в сохраненном ответе.

 

4. Построение ответов из кешей

При представлении запроса кэш НЕ ДОЛЖЕН повторно использовать сохраненный ответ, если:

  • Представленный эффективный URI запроса (Раздел 5.5 [RFC7230 #]) и тот из сохраненного совпадения ответа, и
  • метод запроса, связанный с сохраненным ответом, позволяет использовать его для представленного запроса, и
  • выбор полей заголовка, назначенных сохраненным ответом (если есть), совпадающими с представленными (см. раздел 4.1), и
  • представленный запрос не содержит «no-cache pragma» (раздел 5.4) и директивы «no-cache cache» (раздел 5.2.1), если только сохраненный ответ не был успешно проверен (раздел 4.3), и
  • сохраненный ответ не содержит директивы «no-cache cache» (раздел 5.2.2.2), если он не был успешно проверен (раздел 4.3), и
  • сохраненный ответ:
  • * свежий (см. раздел 4.2) или* разрешено обслуживаться несвежим (см. раздел 4.2.4), или* успешно подтверждено (см. раздел 4.3).

Обратите внимание, что любое из перечисленных выше требований может быть отменено расширением управления кэшем; см. раздел 5.2.3.

Когда сохраненный ответ используется для удовлетворения запроса без проверки, кеш ДОЛЖЕН генерировать поле заголовка Age (раздел 5.1), заменяя любое присутствие в ответе значением, равным current_age сохраненного ответа; см. раздел 4.2.3.

Кэш ДОЛЖЕН записывать запросы с небезопасными методами (раздел 4.2.1 [RFC7231 #]) на исходный сервер; т.е. кешу не разрешено генерировать ответ на такой запрос до того, как он перенаправит запрос и получит соответствующий ответ.

Также обратите внимание, что небезопасные запросы могут сделать недействительными уже сохраненные ответы; см. раздел 4.4.

Когда хранится более одного подходящего ответа, кеш ДОЛЖЕН использовать самый последний ответ (как определено в поле заголовка Date). Он также может переслать запрос с помощью «Cache-Control: max-age=0» или «Cache-Control: no-cache«, чтобы определить, какой ответ использовать.

Кэш, в котором нет доступных часов, НЕ ДОЛЖЕН использовать хранимые ответы без их повторной проверки при каждом использовании.

 

4.1. Вычисление вторичных ключей с помощью Vary

Когда кэш получает запрос, который может быть удовлетворен сохраненным ответом, который имеет поле заголовка Vary (Раздел 7.1.4 [RFC7231 #]), он НЕ ДОЛЖЕН использовать этот ответ, если только все поля заголовка выбора не назначены полем заголовка Vary совпадают как в исходном запросе (т. е. связанном с сохраненным ответом), так и в представленном запросе.

Выбор полей заголовка из двух запросов определяется так, чтобы они соответствовали тогда и только тогда, когда поля первого запроса можно преобразовать в поля второго запроса, применив любое из следующего:

  • добавление или удаление пробелов, где это разрешено в синтаксисе поля заголовка
  • объединение нескольких полей заголовка с одним и тем же именем поля (см. раздел 3.2 [RFC7230 #])
  • нормализация обоих значений полей заголовка способом, который, как известно, имеет идентичную семантику, в соответствии со спецификацией поля заголовка (например, переупорядочение значений поля, когда порядок не имеет значения; нормализация регистра, где значения определены как независимые от регистра)

Если (после какой-либо нормализации, которая может иметь место) поле заголовка отсутствует в запросе, оно может соответствовать другому запросу только в том случае, если оно там также отсутствует.

Значение поля «*» в заголовке Vary всегда не совпадает.

Сохраненный ответ с соответствующими полями заголовка выбора называется выбранным ответом.

Если доступно несколько выбранных ответов (возможно, включая ответы без поля заголовка Vary), кэш должен будет выбрать один для использования. Когда поле заголовка выбора имеет известный механизм для этого (например, qvalues для Accept и аналогичные поля заголовка запроса), этот механизм МОЖЕТ использоваться для выбора предпочтительных ответов; из остатка используется самый последний ответ (как определено в поле заголовка Date), как в Разделе 4.

Если выбранный ответ недоступен, кэш не может удовлетворить представленный запрос. Как правило, он перенаправляется на исходный сервер в (возможно, условном; см. Раздел 4.3) запросе.

 

4.2. Свежесть (Freshness)

Свежий ответ (fresh response) — это тот ответ, чей возраст еще не превысил свою свежесть. И наоборот, устаревший ответ (stale response) — тот, где он есть.

Время жизни свежести ответа (response’s freshness lifetime) — это промежуток времени между его генерацией сервером происхождения и временем его истечения. Явное время истечения (explicit expiration time) — это время, в которое исходный сервер намеревается, что сохраненный ответ больше не может использоваться кешем без дальнейшей проверки, тогда как эвристическое время истечения назначается кешем, когда явное время истечения недоступно.

Возраст ответа (response’s age) — это время, прошедшее с того момента, как оно было создано или успешно проверено исходным сервером.

Когда ответ является «свежим» в кэше, его можно использовать для удовлетворения последующих запросов без обращения к исходному серверу, что повышает эффективность.

Основной механизм определения свежести заключается в том, что исходный сервер должен предоставлять явное время истечения в будущем, используя либо поле заголовка Expires (раздел 5.3), либо директиву ответа max-age (раздел 5.2.2.8). Обычно исходные серверы будут назначать будущие явные времена истечения для ответов, полагая, что представление вряд ли изменится семантически значимым образом до того, как истечет время истечения.

Если исходный сервер желает заставить кэш проверять каждый запрос, он может назначить явное время истечения в прошлом, чтобы указать, что ответ уже устарел. Совместимые кэши обычно проверяют устаревший кэшированный ответ, прежде чем повторно использовать его для последующих запросов (см. Раздел 4.2.4).

Поскольку исходные серверы не всегда предоставляют явное время истечения, кэши также могут использовать эвристику для определения времени истечения при определенных обстоятельствах (см. Раздел 4.2.2).

Вычисление, чтобы определить, является ли ответ новым:

response_is_fresh = (freshness_lifetime > current_age)

freshness_lifetime определено в разделе 4.2.1; current_age определено в разделе 4.2.3.

Клиенты могут отправлять директивы кэша «max-age» или «min-fresh» в запросе, чтобы ограничить или ослабить вычисления свежести для соответствующего ответа (раздел 5.2.1).

При расчете свежести, чтобы избежать распространенных проблем при разборе даты:

  • Хотя все форматы даты указываются с учетом регистра, получатель кэша ДОЛЖЕН сопоставлять имена дней, недель и часовых поясов без учета регистра.
  • Если внутренняя реализация времени получателя кэша имеет меньшее разрешение, чем значение HTTP-даты, получатель ДОЛЖЕН внутренне представить проанализированную дату окончания срока действия как ближайшее время, равное или более раннее, чем полученное значение.
  • Получатель кэша НЕ ДОЛЖЕН разрешать местным часовым поясам влиять на расчет или сравнение возраста или времени истечения.
  • Получателю кэша СЛЕДУЕТ считать дату с сокращением зоны, отличным от GMT или UTC, недействительной для расчета срока действия.

Обратите внимание, что свежесть применяется только к операции кэширования; его нельзя использовать, чтобы заставить пользовательский агент обновить свой дисплей или перезагрузить ресурс. См. Раздел 6 для объяснения различий между кешами и механизмами истории.

 

4.2.1. Расчет свежести жизни

Кэш может вычислить время жизни свежести (обозначается как freshness_lifetime) ответа, используя первое совпадение следующего:

  • Если кэш является общим и присутствует директива ответа «s-maxage» (раздел 5.2.2.9), используйте его значение или
  • Если имеется директива о максимальном возрасте «max-age» (раздел 5.2.2.8), используйте ее значение или
  • Если поле заголовка ответа Expires (раздел 5.3) присутствует, используйте его значение минус значение поля заголовка ответа Date, или
  • В противном случае в ответе отсутствует явное время истечения. Эвристическая свежесть может быть применима; см. раздел 4.2.2.

Обратите внимание, что этот расчет не подвержен перекосу часов, поскольку вся информация поступает с исходного сервера.

Когда для данной директивы присутствует более одного значения (например, два поля заголовка Expires, несколько директив Cache-Control: max-age), значение директивы считается недействительным. Кэшам рекомендуется считать устаревшие ответы, содержащие неверную информацию о свежести.

 

4.2.2. Расчет эвристической свежести

Поскольку исходные серверы не всегда предоставляют явное время истечения, кэш МОЖЕТ назначать эвристическое время истечения, когда явное время не указано, используя алгоритмы, которые используют другие значения поля заголовка (например, время последнего изменения) для оценки вероятного времени истечения. Эта спецификация не предоставляет конкретные алгоритмы, но накладывает ограничения на худшие случаи на их результаты.

Кэш НЕ ДОЛЖЕН использовать эвристику для определения свежести, когда в сохраненном ответе присутствует явное время истечения. Из-за требований Раздела 3 это означает, что фактически эвристика может использоваться только для ответов без явной свежести, чьи коды состояния по умолчанию определены как кешируемые (см. Раздел 6.1 [RFC7231 #]), и тех ответов без явной свежести, которые были помечены как явно кэшируемые (например, с помощью директивы public).

Если в ответе имеется поле заголовка Last-Modified (раздел 2.2 [RFC7232 #]), кэшам рекомендуется использовать эвристическое значение срока действия, которое не превышает некоторой доли интервала с того времени. Типичная настройка этой фракции может составлять 10%.

Когда для вычисления времени жизни свежести используется эвристика, кеш ДОЛЖЕН генерировать в ответе поле заголовка Warning с кодом 113 warn-code (см. Раздел 5.5.4), если его «current_age» больше 24 часов и такого предупреждения еще нет.

Примечание!

Раздел 13.9 [RFC2616 #] запрещает кэшам вычислять эвристическую свежесть для URI с компонентами запросов (т. е. С теми, которые содержат знак вопроса «?»). На практике это не было широко реализовано. Поэтому исходным серверам рекомендуется отправлять явные директивы (например, Cache-Control: no-cache), если они хотят исключить кэширование.

 

4.2.3. Расчет возраста

Поле заголовка «Age» используется для передачи предполагаемого возраста ответного сообщения при получении из кэша. Значение поля Age представляет собой оценку в кэше количества секунд, прошедших с того момента, как ответ был сгенерирован или проверен исходным сервером. По сути, значение Age представляет собой сумму времени, в течение которого ответ находился в каждом из кэшей на пути от исходного сервера, плюс время, которое он проходил по сетевым путям.

Для расчета возраста используются следующие данные:

4.2.3.1. age_value

Термин «age_value» обозначает значение поля заголовка Age (раздел 5.1) в форме, подходящей для арифметической операции; или 0, если не доступно.

 

4.2.3.2. date_value

Термин «date_value» обозначает значение поля заголовка Date в форме, подходящей для арифметических операций. См. Раздел 7.1.1.2 [RFC7231 #] для определения поля заголовка Date и требований относительно ответов без него.

 

4.2.3.3. now

Термин «now» означает «текущее значение часов на хосте, выполняющем вычисления». Хост должен использовать NTP ([RFC5905 #]) или какой-либо аналогичный протокол для синхронизации своих часов с универсальным координированным временем.

4.2.3.4. request_time

Термин «request_time» означает текущее значение часов на хосте в момент выполнения запроса, в результате которого был сохранен ответ.

4.2.3.5. response_time

Термин «response_time» означает текущее значение часов на хосте в момент получения ответа.


Возраст ответа можно рассчитать двумя совершенно независимыми способами:

  1. «visible_age»: response_time минус date_value, если локальные часы достаточно хорошо синхронизированы с часами исходного сервера. Если результат отрицательный, результат заменяется на ноль.
  2. «corrected_age_value», если все кэши вдоль пути ответа реализуют HTTP/1.1. Кэш ДОЛЖЕН интерпретировать это значение относительно времени, когда был инициирован запрос, а не времени, когда был получен ответ.

apparent_age = max(0, response_time - date_value);
response_delay = response_time - request_time;
corrected_age_value = age_value + response_delay;

Они объединены как

corrected_initial_age = max(apparent_age, corrected_age_value);

если только кэш не уверен в значении поля заголовка Age (например, потому что в поле заголовка Via нет прыжков HTTP/1.0), в этом случае значение «corrected_age_value» МОЖЕТ использоваться в качестве «corrected_initial_age«.

«Current_age» сохраненного ответа затем может быть вычислено путем добавления количества времени (в секундах), прошедшего с момента, когда сохраненный ответ был последний раз проверен исходным сервером, к «corrected_initial_age«.

resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;

4.2.4. Обслуживание устаревших ответов

«Устаревшим» (stale) ответом является тот, который либо имеет явную информацию об истечении срока действия, либо ему разрешено рассчитывать эвристический срок действия, но он не является свежим в соответствии с расчетами в разделе 4.2.

Кэш НЕ ДОЛЖЕН генерировать устаревший ответ, если он запрещен явной внутрипротокольной директивой (например, директивой кеша «no-store» или «no-cache«, директивой ответа «must-revalidate«, или применимую директиву ответа «s-maxage» или «proxy-revalidate«; см. раздел 5.2.2).

Кэш НЕ ДОЛЖЕН отправлять устаревшие ответы, если он не отключен (т. е. Он не может связаться с исходным сервером или иным образом найти прямой путь) или если это явно разрешено (например, директивой запроса «max-stale«; см. Раздел 5.2.1)

Кэш ДОЛЖЕН генерировать поле заголовка Warning с кодом 110 предупреждения (см. Раздел 5.5.1) в устаревших ответах. Аналогично, кеш ДОЛЖЕН генерировать 112 предупреждение (см. Раздел 5.5.3) в устаревших ответах, если кеш отключен.

Кэш НЕ ДОЛЖЕН генерировать новое поле заголовка Warning при пересылке ответа, который не имеет поля заголовка Age, даже если ответ уже устарел. Кэш не должен проверять ответ, который просто устарел при передаче.

 

4.3. Проверка (Validation)

Когда кэш-память имеет один или несколько сохраненных ответов для запрошенного URI, но не может обслуживать ни один из них (например, потому что они не являются свежими или не могут быть выбраны; см. Раздел 4.1), он может использовать механизм условного запроса [RFC7232 #] в перенаправленном запросе дать следующему входящему серверу возможность выбрать действительный хранимый ответ для использования, обновления хранимых метаданных в процессе или замены хранимого ответа (ответов) новым ответом. Этот процесс известен как «проверка» (validating) или «повторная проверка» (revalidating) сохраненного ответа.

 

4.3.1. Отправка запроса на проверку

При отправке условного запроса на проверку кэша, кэш отправляет одно или несколько полей заголовка предварительного условия, содержащих метаданные средства проверки, из своих сохраненных ответов, которые затем сравниваются получателями, чтобы определить, эквивалентен ли сохраненный ответ текущему представлению ресурса.

Одним из таких валидаторов является отметка времени (timestamp), заданная в поле заголовка Last-Modified (раздел 2.2 [RFC7232 #]), который можно использовать в поле заголовка If-Modified-Since для проверки ответа или в If-Unmodified-Since или If-Range поля заголовка для выбора представления (т. е. Клиент конкретно ссылается на ранее полученное представление с этой временной меткой).

Другим валидатором является тег сущности (entity-tag), указанный в поле заголовка ETag (Раздел 2.3 [RFC7232 #]). Один или несколько тегов объекта (entity-tag), указывающих один или несколько сохраненных ответов (stored responses), можно использовать в поле заголовка If-None-Match для проверки ответа или в поле заголовка If-Match или If-Range для выбора представления (т. е. Клиента конкретно относится к одному или нескольким ранее полученным представлениям с перечисленными тегами сущностей).

 

4.3.2. Обработка полученного запроса на проверку

Каждый клиент в цепочке запросов может иметь свой собственный кэш, поэтому для кеша посредника характерно получение условных запросов от других (исходящих) кешей. Аналогично, некоторые пользовательские агенты используют условные запросы, чтобы ограничить передачу данных недавно измененными представлениями или завершить передачу частично извлеченного представления.

Если кэш получает запрос, который может быть удовлетворен путем повторного использования одного из его сохраненных ответов 200 (ОК) или 206 (частичное содержимое), кэш ДОЛЖЕН оценить любые применимые предварительные условия поля условного заголовка, полученные в этом запросе, в отношении соответствующих валидаторов, содержащихся в выбранных ответах. Кэш НЕ ДОЛЖЕН оценивать поля условных заголовков, которые применимы только к серверу происхождения, найдены в запросе с семантикой, которая не может быть удовлетворена кэшированным ответом, или применены к целевому ресурсу, для которого у него нет сохраненных ответов; такие предварительные условия, вероятно, предназначены для какого-либо других (входящего) серверов.

Надлежащая оценка условных запросов кэшем зависит от полученных полей заголовка предварительного условия и их приоритета, как определено в Разделе 6 [RFC7232 #]. Поля условного заголовка If-Match и If-Unmodified-Since не применимы к кешу.

Запрос, содержащий поле заголовка If-None-Match (раздел 3.2 [RFC7232 #]), указывает, что клиент хочет проверить один или несколько своих собственных сохраненных ответов по сравнению с тем, какой хранимый ответ выбран кешем. Если значение поля равно звёздочке «*», или если значение поля является списком тегов объекта и, по крайней мере, один из них соответствует тегу объекта выбранного сохраненного ответа, получателю кэша СЛЕДУЕТ генерировать 304 (не изменено) ответ (с использованием метаданных выбранного сохраненного ответа) вместо отправки этого сохраненного ответа.

Когда кэш решает повторно проверить свои собственные сохраненные ответы на запрос, который содержит список тегов объекта If-None-Match, кэш МОЖЕТ объединить полученный список со списком тегов объекта из своего собственного сохраненного набора ответов («свежий или устарел» — «fresh or stale») и отправляет объединение двух списков в качестве значения поля заголовка замены If-None-Match в перенаправленном запросе. Если сохраненный ответ содержит только частичное содержимое, кеш НЕ ДОЛЖЕН включать свой тег объекта в объединение, если только запрос не соответствует диапазону, который будет полностью удовлетворен этим частичным сохраненным ответом. Если ответ на перенаправленный запрос равен 304 (не изменен) и имеет значение поля заголовка ETag с тегом объекта, которого нет в списке клиента, кэш ДОЛЖЕН сгенерировать ответ 200 (ОК) для клиента путем повторного использования его соответствующего сохраненного ответа, обновленного метаданными ответа 304 (раздел 4.3.4).

Если поле заголовка If-None-Match отсутствует, запрос, содержащий поле заголовка If-Modified-Since (раздел 3.3 [RFC7232 #]), указывает, что клиент хочет проверить один или несколько своих собственных сохраненных ответов по дате изменения, Получатель кэша ДОЛЖЕН сгенерировать ответ 304 (не измененный) (используя метаданные выбранного сохраненного ответа), если один из следующих случаев является истинным: 1) выбранный сохраненный ответ имеет значение поля Last-Modified, которое является более ранним, чем или равно условной метке времени; 2) поле Last-Modified отсутствует в выбранном сохраненном ответе, но оно имеет значение поля Date, которое раньше или равно условной метке времени; или, 3) ни Last-Modified, ни Date не присутствуют в выбранном сохраненном ответе, но в кеше записывается, что он был получен за время, ранее или равное условной отметке времени.

Кэш, который реализует частичные ответы на запросы диапазона, как определено в [RFC7233 #], также должен оценивать полученное поле заголовка If-Range (раздел 3.2 [RFC7233 #]) относительно его выбранного сохраненного ответа.

 

4.3.3. Обработка ответа на валидацию

Обработка кэша ответа на условный запрос зависит от его кода состояния:

  • Код состояния ответа 304 (не изменен) указывает, что сохраненный ответ может быть обновлен и использован повторно; см. раздел 4.3.4.
  • Полный ответ (то есть ответ с телом полезной нагрузки) указывает, что ни один из сохраненных ответов, назначенных в условном запросе, не подходит. Вместо этого кеш ДОЛЖЕН использовать полный ответ для удовлетворения запроса и МОЖЕТ заменить сохраненные ответы.
  • Однако, если кэш получает ответ 5xx (Ошибка сервера) при попытке проверить ответ, он может либо переслать этот ответ запрашивающему клиенту, либо действовать так, как если бы сервер не ответил. В последнем случае кеш МОЖЕТ отправить ранее сохраненный ответ (см. Раздел 4.2.4).

 

4.3.4. Обновление сохраненных ответов при проверке

Когда кэш получает ответ 304 (не изменен) и уже имеет один или несколько сохраненных 200 (ОК) ответов для одного и того же ключа кэша, кэш должен идентифицировать, какой из сохраненных ответов обновляется этим новым ответом, а затем обновлять сохраненный ответ (ы) с новой информацией, представленной в ответе 304.

Сохраненный ответ на обновление идентифицируется с помощью первого совпадения (если есть) из следующего:

  • Если новый ответ содержит строгий валидатор (см. раздел 2.1 [RFC7232 #]), то этот строгий валидатор идентифицирует выбранное представление для обновления. Все сохраненные ответы с одинаковым строгим валидатором будут выбраны. Если ни один из сохраненных ответов не содержит такой же строгий валидатор, то кэш НЕ ДОЛЖЕН использовать новый ответ для обновления любых сохраненных ответов.
  • Если новый ответ содержит слабый валидатор, и этот валидатор соответствует одному из сохраненных ответов в кэше, то для обновления выбирается самый последний из этих совпадающих сохраненных ответов.
  • Если новый ответ не включает какую-либо форму валидатора (например, в случае, когда клиент генерирует запрос If-Modified-Since из источника, отличного от поля заголовка ответа Last-Modified), и существует только один сохраненный ответ и этот сохраненный ответ также не имеет валидатора, тогда этот сохраненный ответ выбирается для обновления.

Если для обновления выбран сохраненный ответ, кеш ДОЛЖЕН:

  • удалить все поля заголовка Warning в сохраненном ответе с кодом предупреждения 1xx (см. раздел 5.5);
  • сохранить любые поля заголовка Warning в сохраненном ответе с кодом предупреждения 2xx; а также,
  • использовать другие поля заголовка, предоставленные в ответе 304 (не изменено), чтобы заменить все экземпляры соответствующих полей заголовка в сохраненном ответе.

 

4.3.5. Освежение ответов через метод HEAD

Ответ на метод HEAD идентичен тому, что был бы эквивалентный запрос, сделанный с помощью GET, за исключением того, что в нем отсутствует тело. Это свойство ответов HEAD можно использовать для аннулирования или обновления кэшированного ответа GET, если более эффективный механизм условного запроса GET недоступен (из-за отсутствия валидаторов, присутствующих в сохраненном ответе) или если передача тела представления нежелательна даже если это изменилось.

Когда кэш выполняет входящий запрос HEAD для данной цели запроса и получает ответ 200 (ОК), кэш ДОЛЖЕН обновить или аннулировать каждый из своих сохраненных ответов GET, которые могли быть выбраны для этого запроса (см. Раздел 4.1).

Для каждого из сохраненных ответов, которые могли быть выбраны, если сохраненный ответ и ответ HEAD имеют совпадающие значения для любых полученных полей валидатора (ETag и Last-Modified) и, если ответ HEAD имеет поле заголовка Content-Length, значение Content-Length совпадает с сохраненным ответом, кэш ДОЛЖЕН обновить хранимый ответ, как описано ниже; в противном случае кеш ДОЛЖЕН считать сохраненный ответ устаревшим.

Если кэш обновляет сохраненный ответ метаданными, предоставленными в ответе HEAD, кеш ДОЛЖЕН:

  • удалить все поля заголовка Warning в сохраненном ответе с кодом предупреждения 1xx (см. раздел 5.5);
  • сохранить любые поля заголовка Warning в сохраненном ответе с кодом предупреждения 2xx; а также,
  • использовать другие поля заголовка, предоставленные в ответе HEAD, чтобы заменить все экземпляры соответствующих полей заголовка в сохраненном ответе и добавить новые поля заголовка в раздел заголовка хранимого ответа, если иное не ограничено полем заголовка Cache-Control.

 

4.4. Невалидность (Признание недействительным)

Поскольку небезопасные методы запроса (Раздел 4.2.1 [RFC7231 #]), такие как PUT, POST или DELETE, потенциально могут изменять состояние на исходном сервере, промежуточные кэши могут использовать их для обновления своего содержимого.

Кэш ДОЛЖЕН сделать недействительным действующий URI запроса (раздел 5.5 [RFC7230 #]), а также URI в полях заголовка ответа Location и Content-Location (если имеется), когда статус кода «не-ошибочный» в ответ на небезопасный метод запроса.

Однако кеш НЕ ДОЛЖЕН делать недействительным URI из поля заголовка ответа Location или Content-Location, если часть хоста этого URI отличается от части хоста в действующем URI запроса (Раздел 5.5 [RFC7230 #]). Это помогает предотвратить атаки типа «отказ в обслуживании».

Кэш ДОЛЖЕН аннулировать действующий URI запроса (раздел 5.5 [RFC7230 #]), когда он получает ответ без ошибок на запрос методом, безопасность которого неизвестна.

Здесь «ответ без ошибок» («non-error response«) — это ответ с кодом состояния 2xx (Успешно) или 3xx (Перенаправление). «Invalidate» означает, что кэш либо удалит все сохраненные ответы, относящиеся к действующему URI запроса, либо пометит их как «недействительные» и нуждается в обязательной проверке, прежде чем их можно будет отправить в ответ на последующий запрос.

Обратите внимание, что это не гарантирует, что все соответствующие ответы будут признаны недействительными. Например, запрос на изменение состояния может сделать недействительными ответы в кэшах, через которые он проходит, но соответствующие ответы все еще могут храниться в других кэшах, которых он не имеет.

 

5. Определения полей заголовка

Этот раздел определяет синтаксис и семантику полей заголовка HTTP/1.1, связанных с кэшированием.

 

5.1. Заголовок Age

Поле заголовка «Age» передает оценку отправителя количества времени, прошедшего с того момента, как ответ был сгенерирован или успешно подтвержден на исходном сервере. Возрастные значения рассчитываются, как указано в разделе 4.2.3.

Age = delta-seconds

Значение поля Age является неотрицательным целым числом, представляющим время в секундах (см. Раздел 1.2.1).

Наличие поля заголовка Age означает, что ответ не был создан или проверен исходным сервером для этого запроса. Однако отсутствие поля заголовка Age не означает, что с источником связались, поскольку ответ мог быть получен из кэша HTTP/1.0, в котором не реализован Age.

 

5.2. Заголовок Cache-Control

Поле заголовка «Cache-Control» используется для указания директив для кешей в цепочке запросов / ответов. Такие директивы кэша являются однонаправленными в том смысле, что наличие директивы в запросе не означает, что в ответе должна быть указана та же директива.

Кэш ДОЛЖЕН соответствовать требованиям директив Cache-Control, определенных в этом разделе. См. Раздел 5.2.3 для получения информации о том, как обрабатываются директивы Cache-Control, определенные в другом месте.

Примечание!

Некоторые кэши HTTP/1.0 могут не реализовывать Cache-Control.

Прокси, независимо от того, реализует он кеш или нет, ДОЛЖЕН передавать директивы кеша в перенаправленных сообщениях, независимо от их значения для этого приложения, поскольку директивы могут быть применимы ко всем получателям в цепочке запросов / ответов. Невозможно направить директиву на конкретный кеш.

Директивы кэша идентифицируются токеном, который сравнивается без учета регистра и имеют необязательный аргумент, который может использовать синтаксис как токена, так и строки в кавычках. Для определенных ниже директив, определяющих аргументы, получатели должны принимать обе формы, даже если одна из них задокументирована как предпочтительная. Для любой директивы, не определенной в этой спецификации, получатель ДОЛЖЕН принять обе формы.

Cache-Control = 1#cache-directive
cache-directive = token [ "=" ( token / quoted-string ) ]

Для директив кеша, определенных ниже, ни один аргумент не определен (и не разрешен), если не указано иное.

5.2.1. Директивы запроса Cache-Control

5.2.1.1. max-age

Синтаксис аргумента:

delta-seconds (смотри Раздел 1.2.1)

Директива запроса «max-age» указывает, что клиент не желает принимать ответ, чей возраст превышает указанное количество секунд. Если директива запроса max-stale также не присутствует, клиент не желает принимать устаревший ответ.

Эта директива использует маркерную форму синтаксиса аргумента: например, ’max-age=5’ not ’max-age=»5″’. Отправителю НЕ СЛЕДУЕТ генерировать форму в кавычках.

5.2.1.2. max-stale

Синтаксис аргумента:

delta-seconds (смотри Раздел 1.2.1)

Директива запроса «max-stale» указывает, что клиент готов принять ответ, который превысил срок своей свежести. Если max-stale назначено значение, то клиент готов принять ответ, который превысил срок действия своей свежести не более чем на указанное количество секунд. Если значение max-stale не назначено, то клиент готов принять устаревший ответ любого возраста.

Эта директива использует маркерную форму синтаксиса аргумента: например, ‘max-stale = 10’, а не ‘max-stale = «10» ’. Отправителю НЕ СЛЕДУЕТ генерировать форму в кавычках.

5.2.1.3. min-fresh

Синтаксис аргумента:

delta-seconds (смотри Раздел 1.2.1)

Директива запроса «min-fresh» указывает, что клиент готов принять ответ, время жизни которого не меньше его текущего возраста плюс указанное время в секундах. То есть клиент хочет получить ответ, который все еще будет свежим, по крайней мере, в течение указанного количества секунд.

Эта директива использует маркерную форму синтаксиса аргумента: например, ‘min-fresh = 20’, а не ‘min-fresh = «20»‘. Отправителю НЕ СЛЕДУЕТ генерировать форму в кавычках.

5.2.1.4. no-cache

Директива запроса «no-cache» указывает, что кеш НЕ ДОЛЖЕН использовать сохраненный ответ для удовлетворения запроса без успешной проверки на исходном сервере.

5.2.1.5. no-store

Директива запроса «no-store» указывает, что кеш НЕ ДОЛЖЕН хранить какую-либо часть этого запроса или любой ответ на него. Эта директива применяется как к частным, так и к общим кэшам. «НЕ ДОЛЖЕН хранить» в этом контексте означает, что кэш НЕ ДОЛЖЕН преднамеренно хранить информацию в энергонезависимом хранилище и ДОЛЖЕН приложить максимальные усилия для удаления информации из энергозависимого хранилища как можно быстрее после ее пересылки.

Эта директива НЕ является надежным или достаточным механизмом обеспечения конфиденциальности. В частности, злонамеренные или скомпрометированные кэши могут не распознавать или не подчиняться этой директиве, а коммуникационные сети могут быть уязвимы для прослушивания.

Обратите внимание, что если запрос, содержащий эту директиву, выполняется из кэша, директива запроса no-store не применяется к уже сохраненному ответу.

5.2.1.6. no-transform

Директива запроса «no-transform» (без преобразования) указывает, что посредник (независимо от того, реализует ли он кэш) НЕ ДОЛЖЕН преобразовывать полезную нагрузку, как определено в Разделе 5.7.2 [RFC7230 #].

5.2.1.7. only-if-cached

Директива запроса «only-if-cached» указывает, что клиент желает получить только сохраненный ответ. Если он получает эту директиву, кеш ДОЛЖЕН или ответить, используя сохраненный ответ, который согласуется с другими ограничениями запроса, или ответить кодом состояния 504 (время ожидания шлюза). Если группа кэшей работает как единая система с хорошими внутренними связями, членский кеш МОЖЕТ направлять такой запрос в эту группу кешей.

5.2.2. Директивы ответа Cache-Control

5.2.2.1. must-revalidate

Директива ответа «must-revalidate» указывает, что, как только он устарел, кеш НЕ ДОЛЖЕН использовать ответ для удовлетворения последующих запросов без успешной проверки на исходном сервере.

Директива must-revalidate необходима для поддержки надежной работы определенных функций протокола. При любых обстоятельствах кеш ДОЛЖЕН подчиняться директиве must-revalidate; в частности, если кеш не может достичь исходного сервера по какой-либо причине, он ДОЛЖЕН сгенерировать ответ 504 (время ожидания шлюза).

Директива must-revalidate должна использоваться серверами тогда и только тогда, когда неудача при проверке запроса на представление может привести к некорректной работе, такой как молчаливая неисполненная финансовая транзакция (silently unexecuted financial transaction).

5.2.2.2. no-cache

Синтаксис аргумента:

#field-name

Директива ответа «no-cache» указывает, что ответ НЕ ДОЛЖЕН использоваться для удовлетворения последующего запроса без успешной проверки на исходном сервере. Это позволяет исходному серверу предотвращать использование его кешем для удовлетворения запроса, не связываясь с ним, даже кешами, которые были настроены для отправки устаревших ответов.

Если в директиве ответа без кэширования указано одно или несколько имен полей, то кэш МОЖЕТ использовать ответ для удовлетворения последующего запроса с учетом любых других ограничений кэширования. Однако любые поля заголовка в ответе, в которых указаны имена полей, НЕ ДОЛЖНЫ отправляться в ответе на последующий запрос без успешной повторной проверки с сервером происхождения. Это позволяет исходному серверу предотвратить повторное использование определенных полей заголовка в ответе, в то же время позволяя кэшировать остальную часть ответа.

Указанные имена полей не ограничены набором полей заголовка, определенных в этой спецификации. Имена полей не чувствительны к регистру.

Эта директива использует форму строки в кавычках синтаксиса аргумента. Отправителю НЕ СЛЕДУЕТ генерировать форму токена (даже если для списков с одним входом цитирование не требуется).

Примечание!

Несмотря на то, что он был перенесен во многие реализации, некоторые кэши HTTP/1.0 не будут распознавать или подчиняться этой директиве. Кроме того, директивы ответа без кэширования с именами полей часто обрабатываются кешами, как если бы была получена неквалифицированная директива без кэширования; то есть, специальная обработка для квалифицированной формы широко не применяется.

 

5.2.2.3. no-store

Директива ответа «no-store» указывает, что кеш НЕ ДОЛЖЕН хранить какую-либо часть немедленного запроса или ответа. Эта директива применяется как к частным, так и к общим кэшам. «НЕ ДОЛЖЕН хранить» в этом контексте означает, что кэш НЕ ДОЛЖЕН преднамеренно хранить информацию в энергонезависимом хранилище и ДОЛЖЕН приложить максимальные усилия для удаления информации из энергозависимого хранилища как можно быстрее после ее пересылки.

Эта директива НЕ является надежным или достаточным механизмом обеспечения конфиденциальности. В частности, злонамеренные или скомпрометированные кэши могут не распознавать или не подчиняться этой директиве, а коммуникационные сети могут быть уязвимы для прослушивания.

5.2.2.4. no-transform

Директива ответа «no-transform» (без преобразования) указывает, что посредник (независимо от того, реализует ли он кэш) НЕ ДОЛЖЕН преобразовывать полезную нагрузку, как определено в Разделе 5.7.2 [RFC7230 #].

5.2.2.5. public

Директива ответа «public» указывает, что любой кеш МОЖЕТ хранить ответ, даже если ответ обычно не кешируется или кешируется только в частном кеше. (См. Раздел 3.2 для получения дополнительной информации, касающейся использования public в ответ на запрос, содержащий авторизацию, и раздел 3 для получения подробной информации о том, как public влияет на ответы, которые обычно не хранятся, поскольку их коды состояния по умолчанию не определяются как кэшируемые. см. раздел 4.2.2.)

5.2.2.6. private

Синтаксис аргумента:

#field-name

Директива ответа «private» указывает, что ответное сообщение предназначено для одного пользователя и НЕ ДОЛЖНО храниться в общем кэше. Частный кеш МОЖЕТ хранить ответ и повторно использовать его для более поздних запросов, даже если ответ обычно не кэшируется.

Если директива частного ответа задает одно или несколько имен полей, это требование ограничивается значениями полей, связанными с перечисленными полями заголовка ответа. То есть общий кеш НЕ ДОЛЖЕН хранить указанные имена полей, тогда как он МОЖЕТ хранить оставшуюся часть ответного сообщения.

Указанные имена полей не ограничены набором полей заголовка, определенных в этой спецификации. Имена полей не чувствительны к регистру.

Эта директива использует форму строки в кавычках синтаксиса аргумента. Отправителю НЕ СЛЕДУЕТ генерировать форму токена (даже если для списков с одним входом цитирование не требуется).

Примечание!

Это использование слова «private» (приватный) только контролирует, где может храниться ответ; он не может обеспечить конфиденциальность содержимого сообщения. Кроме того, частные директивы ответа с именами полей часто обрабатываются кешами, как если бы получена неквалифицированная частная директива; то есть, специальная обработка для квалифицированной формы широко не применяется.

 

5.2.2.7. proxy-revalidate

Директива ответа «proxy-revalidate» имеет то же значение, что и директива ответа «must-revalidate«, за исключением того, что она не применяется к частным кэшам.

5.2.2.8. max-age

Синтаксис аргумента:

delta-seconds (смотри Раздел 1.2.1)

Директива ответа «max-age» указывает, что ответ считается устаревшим после того, как его возраст превышает указанное количество секунд.

Эта директива использует маркерную форму синтаксиса аргумента: например, ‘max-age = 5’, а не ‘max-age = «5»‘. Отправителю НЕ СЛЕДУЕТ генерировать форму в кавычках.

5.2.2.9. s-maxage

Синтаксис аргумента:

delta-seconds (смотри Раздел 1.2.1)

Директива ответа «s-maxage» указывает, что в совместно используемых кэшах максимальный возраст, указанный в этой директиве, переопределяет максимальный возраст, указанный в директиве max-age или в поле заголовка Expires. Директива «s-maxage» также подразумевает семантику директивы ответа proxy-revalidate.

Эта директива использует маркерную форму синтаксиса аргумента: например, ’s-maxage = 10’ not ’s-maxage =« 10 »’. Отправителю НЕ СЛЕДУЕТ генерировать форму в кавычках.

5.2.3. Расширения контроля кэша

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

Информационные расширения (те, которые не требуют изменения поведения кэша) могут быть добавлены без изменения семантики других директив.

Поведенческие расширения предназначены для работы, действуя как модификаторы существующей базы директив кеша. Поставляются как новая директива, так и старая директива, так что приложения, которые не понимают новую директиву, будут по умолчанию использовать поведение, заданное старой директивой, а те, которые понимают новую директиву, распознают ее как изменяющую требования, связанные со старой директивы. Таким образом, расширения существующих директив управления кэшем могут быть сделаны без нарушения развернутых кэшей.

Например, рассмотрим гипотетическую директиву нового ответа под названием «community» (сообщество), которая действует как модификатор частной директивы: в дополнение к частным кешам любой кеш, который используется только членами именованного сообщества, может кэшировать ответ. Исходный сервер, желающий разрешить сообществу UCI использовать частный ответ в своих общих кэшах, мог бы сделать это, включив

Cache-Control: private, community="UCI"

Кэш, который распознает такое расширение кэша сообщества, может расширить свое поведение в соответствии с этим расширением. Кэш, который не распознает расширение кэша сообщества, будет игнорировать его и придерживаться директивы private.

 

5.3. Заголовок Expires

В поле заголовка «Expires» указывается дата/время, после которого ответ считается устаревшим. См. Раздел 4.2 для дальнейшего обсуждения модели свежести.

Наличие поля Expires не означает, что исходный ресурс изменится или перестанет существовать «в», «до» или «после» этого времени.

Значение Expires является отметкой времени HTTP-даты, как определено в Разделе 7.1.1.1 [RFC7231 #].

Expires = HTTP-date

Например

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Получатель кэша ДОЛЖЕН интерпретировать недопустимые форматы даты, особенно значение «0», как представляющие время в прошлом (т. е. «Уже истекло» — «already expired»).

Если ответ содержит поле Cache-Control с директивой max-age (раздел 5.2.2.8), получатель ДОЛЖЕН игнорировать поле Expires. Аналогично, если ответ включает в себя директиву s-maxage (раздел 5.2.2.9), получатель общего кэша ДОЛЖЕН игнорировать поле Expires. В обоих этих случаях значение в Expires предназначено только для получателей, которые еще не реализовали поле Cache-Control.

Исходный сервер без часов НЕ ДОЛЖЕН генерировать поле Expires, если только его значение не представляет фиксированное время в прошлом (всегда истекло) или его значение не было связано с ресурсом системой или пользователем с надежными часами.

Исторически HTTP требовал, чтобы значение поля Expires не превышало года. Хотя более длительные времена жизни свежести больше не запрещены, было продемонстрировано, что чрезвычайно большие значения вызывают проблемы (например, переполнение часов из-за использования 32-разрядных целых чисел для значений времени), и многие кэши будут выдавать ответ гораздо раньше, чем этот.

 

5.4. Заголовок Pragma

Поле заголовка «Pragma» обеспечивает обратную совместимость с кешами HTTP/1.0, так что клиенты могут указать запрос «no-cache» (без кэширования), который они поймут (поскольку Cache-Control не был определен до HTTP/1.1). Когда поле заголовка Cache-Control также присутствует и понимается в запросе, Pragma игнорируется.

В HTTP/1.0 заголовок Pragma был определен как расширяемое поле для заданных реализацией директив для получателей. Эта спецификация не поддерживает такие расширения для улучшения совместимости.

Pragma = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]

Когда поле заголовка Cache-Control отсутствует в запросе, кэши ДОЛЖНЫ считать, что прагма-директива запроса no-cache имеет такой же эффект, как если бы присутствовало «Cache-Control: no-cache» (см. Раздел 5.2.1) ,

При отправке запроса «no-cache» (без кэширования) клиент должен включать директивы pragma и cache-control, если только Cache-Control: no-cache специально не опущен для нацеливания других директив ответа Cache-Control на кеш HTTP/1.1. Например:

GET / HTTP/1.1
Host: www.example.com
Cache-Control: max-age=30
Pragma: no-cache

будет ограничивать кэши HTTP/1.1 для обслуживания ответа не старше 30 секунд, исключая при этом реализации, которые не понимают Cache-Control, от обслуживания кэшированного ответа.

Примечание. Поскольку значение «Pragma: no-cache» в ответах не указано, оно не обеспечивает надежной замены «Cache-Control: no-cache» в них.

 

5.5. Заголовок Warning

Поле заголовка «Warning» (Предупреждение) используется для передачи дополнительной информации о состоянии или преобразовании сообщения, которое может не отражаться в коде состояния. Эта информация обычно используется для предупреждения о возможной некорректности, вызванной операциями кэширования или преобразованиями, примененными к полезной нагрузке сообщения.

«Warning» (Предупреждения) могут быть использованы для других целей, как связанных с кэшем, так и для других целей. Использование предупреждения, а не кода ошибки, отличает эти ответы от истинных сбоев.

Поля заголовка «Warning» (Предупреждение) в общем случае могут применяться к любому сообщению, однако некоторые коды предупреждений относятся только к кэшам и могут применяться только к ответным сообщениям.

Warning = 1#warning-value

warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date ]

warn-code = 3DIGIT
warn-agent = ( uri-host [ ":" port ] ) / pseudonym
; the name or pseudonym of the server adding
; the Warning header field, for use in debugging
; a single "-" is recommended when agent unknown
warn-text = quoted-string
warn-date = DQUOTE HTTP-date DQUOTE

В ответ может быть сгенерировано несколько предупреждений (исходным сервером или кэшем), включая несколько предупреждений с одинаковым номером кода предупреждения, которые отличаются только текстом предупреждения.

Пользовательский агент, который получает одно или несколько полей заголовка Warning, ДОЛЖЕН проинформировать пользователя о максимально возможном их количестве в порядке их появления в ответе. Отправителям, которые генерируют несколько полей заголовка Warning, рекомендуется упорядочить их с учетом этого поведения агента пользователя. Отправитель, который генерирует новые поля заголовка Warning, ДОЛЖЕН добавлять их после любых существующих полей заголовка Warning.

 

Предупреждениям присваиваются трехзначные предупреждающие коды. Первая цифра указывает, требуется ли удалять предупреждение из сохраненного ответа после проверки:

  • 1xx-коды предупреждений описывают свежесть или статус проверки ответа, и поэтому они ДОЛЖНЫ быть удалены кэшем после проверки. Они могут быть сгенерированы только кэшем при проверке кэшированной записи и НЕ ДОЛЖНЫ генерироваться в любой другой ситуации.
  • 2xx-коды предупреждений описывают некоторый аспект представления, который не исправляется проверкой (например, сжатие представления с потерями), и они НЕ ДОЛЖНЫ быть удалены кэшем после проверки, если не отправлен полный ответ, в котором на случай, если они ДОЛЖНЫ быть.

Если отправитель генерирует один или несколько кодов предупреждений 1xx в сообщении для отправки получателю, который, как известно, использует только HTTP/1.0, отправитель ДОЛЖЕН включить в каждое соответствующее значение предупреждения дату предупреждения, соответствующую полю заголовка Date в сообщение. Например:

HTTP/1.1 200 OK
Date: Sat, 25 Aug 2012 23:34:45 GMT
Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"

Предупреждения имеют сопровождающий текст предупреждения, который описывает ошибку, например, для регистрации. Он носит рекомендательный характер, и его содержание не влияет на интерпретацию кода предупреждения.

Если получатель, использующий, оценивающий или отображающий поля заголовка Warning, получает дату предупреждения, которая отличается от значения даты в том же сообщении, получатель ДОЛЖЕН исключить значение предупреждения, содержащее эту дату предупреждения, перед сохранением, пересылкой или использованием сообщения. Это позволяет получателям исключать значения предупреждений, которые были неправильно сохранены после проверки кэша. Если все значения предупреждений исключены, получатель ДОЛЖЕН также исключить поле заголовка Warning.

Следующие коды предупреждений определяются этой спецификацией, каждый с рекомендуемым текстом предупреждения на английском языке и описанием его значения. Процедура определения дополнительных кодов предупреждений описана в разделе 7.2.1.

5.5.1. Предупреждение: 110 — «Ответ устарел»

Warning: 110 — «Response is Stale»

Кэш ДОЛЖЕН генерировать это всякий раз, когда отправленный ответ устарел.

5.5.2. Предупреждение: 111 — «Сбой повторной проверки»

Warning: 111 — «Revalidation Failed»

Кэш ДОЛЖЕН генерировать это при отправке устаревшего ответа, поскольку попытка подтверждения ответа не удалась из-за невозможности связаться с сервером.

5.5.3. Предупреждение: 112 — «Отключенная операция»

Warning: 112 — «Disconnected Operation»

Кэш ДОЛЖЕН генерировать это, если он намеренно отключен от остальной части сети на период времени.

5.5.4. Предупреждение: 113 — «Эвристическое истечение срока»

Warning: 113 — «Heuristic Expiration»

Кэш ДОЛЖЕН генерировать это, если он эвристически выбрал время жизни свежести более 24 часов, а возраст ответа — более 24 часов.

5.5.5. Предупреждение: 199 — «Разное предупреждение»

Warning: 199 — «Miscellaneous Warning»

Текст предупреждения может содержать произвольную информацию, которая должна быть представлена пользователю или записана в журнал. Система, получающая это предупреждение, НЕ ДОЛЖНА предпринимать какие-либо автоматические действия, кроме как представить предупреждение пользователю.

5.5.6. Предупреждение: 214 — «Преобразование применено»

Warning: 214 — «Transformation Applied»

Этот код предупреждения ДОЛЖЕН быть добавлен прокси-сервером, если он применяет любое преобразование к представлению, такое как изменение кодировки содержимого, медиа-типа или изменение данных представления, если этот код предупреждения уже не присутствует в ответе.

5.5.7. Предупреждение: 299 — «Разное постоянное предупреждение»

Warning: 299 — «Miscellaneous Persistent Warning»

Текст предупреждения может содержать произвольную информацию, которая должна быть представлена пользователю или записана в журнал. Система, получающая это предупреждение, НЕ ДОЛЖНА предпринимать никаких автоматических действий.

 

6. Списки истории

Пользовательские агенты (например, браузеры) часто имеют механизмы истории, такие как кнопки «Back» (Назад) и списки истории, которые можно использовать для повторного отображения представления, полученного ранее в сеансе.

Модель свежести (раздел 4.2) не обязательно применяется к механизмам истории. То есть механизм истории может отображать предыдущее представление, даже если срок его действия истек.

Это не запрещает механизму истории сообщать пользователю, что представление может быть устаревшим, или соблюдать директивы кэша (например, Cache-Control: no-store).

 

7. Соображения IANA

7.1. Реестр кеша

«Реестр директив кэша протокола передачи гипертекста (HTTP)» определяет пространство имен для директив кэша. Он был создан и теперь поддерживается по адресу <http://www.iana.org/assignments/http-cache-directives>.

7.1.1. Процедура

Регистрация ДОЛЖНА включать следующие поля:

  • Имя директивы кэша
  • Указатель на текст спецификации

Значения, которые необходимо добавить в это пространство имен, требуют проверки IETF (см. [RFC5226 #], раздел 4.1).

7.1.2. Соображения по поводу новых директив управления кэшем

Новые директивы расширения должны учитывать определение:

  • Что означает указание директивы несколько раз,
  • Когда директива не принимает аргумент, что это означает, когда аргумент присутствует,
  • Когда директива требует аргумента, что это означает, когда она отсутствует,
  • Является ли директива специфичной для запросов, ответов или может использоваться в обоих.

См. Также раздел 5.2.3.

7.1.3. Регистрации

Реестр заполнен регистрациями ниже:

Директива кэша (Cache Directive) Определено в  …
max-age Раздел 5.2.1.1 и Раздел 5.2.2.8
max-stale Раздел 5.2.1.2
min-fresh Раздел 5.2.1.3
must-revalidate Раздел 5.2.2.1
no-cache Раздел 5.2.1.4 и Раздел 5.2.2.2
no-store Раздел 5.2.1.5 и Раздел 5.2.2.3
no-transform Раздел 5.2.1.6 и Раздел 5.2.2.4
only-if-cached Раздел 5.2.1.7
private Раздел 5.2.2.6
proxy-revalidate Раздел 5.2.2.7
public Раздел 5.2.2.5
s-maxage Раздел 5.2.2.9
stale-if-error [RFC5861 #], Раздел 4
stale-while-revalidate [RFC5861 #], Раздел 3

Таблица

7.2. Реестр кодов предупреждений

Реестр «Коды предупреждений протокола передачи гипертекста (HTTP)» определяет пространство имен для кодов предупреждений. Он был создан и теперь поддерживается по адресу <http://www.iana.org/assignments/http-warn-codes>.

 

7.2.1. Процедура

Регистрация ДОЛЖНА включать следующие поля:

  • Предупредительный код (3 цифры)
  • Краткое описание
  • Указатель на текст спецификации

Значения, которые необходимо добавить в это пространство имен, требуют проверки IETF (см. [RFC5226 #], раздел 4.1).

7.2.2. Регистрации

Реестр заполнен регистрациями ниже:

Код предупреждения (Warn Code) Короткое описание (Short Description) Определено в  …
110 Response is Stale Раздел 5.5.1
111 Revalidation Failed Раздел 5.5.2
112 Disconnected Operation Раздел 5.5.3
113 Heuristic Expiration Раздел 5.5.4
199 Miscellaneous Warning Раздел 5.5.5
214 Transformation Applied Раздел 5.5.6
299 Miscellaneous Persistent Warning Раздел 5.5.7

Таблица

 

7.3. Регистрация поля заголовка

Поля заголовка HTTP регистрируются в реестре «Заголовки сообщений», который ведется по адресу <http://www.iana.org/assignments/message-headers/>.

Этот документ определяет следующие поля заголовка HTTP, поэтому реестр «Имена полей заголовка постоянного сообщения» был соответствующим образом обновлен (см. [BCP90]).

Имя поля заголовка Протокол (Protocol) Статус (Status) Определено в  …
Age http standard Раздел 5.1
Cache-Control http standard Раздел 5.2
Expires http standard Раздел 5.3
Pragma http standard Раздел 5.4
Warning http standard Раздел 5.5

Таблица

Контроллер изменений: «IETF (iesg@ietf.org) — Целевая рабочая группа по Интернету».

 

8. Вопросы безопасности

Этот раздел предназначен для информирования разработчиков, поставщиков информации и пользователей об известных проблемах безопасности, связанных с кэшированием HTTP. Более общие соображения безопасности рассматриваются в сообщениях HTTP [RFC7230 #] и семантике [RFC7231 #].

Кэши раскрывают дополнительные потенциальные уязвимости, поскольку содержимое кеша представляет собой привлекательную цель для злонамеренной эксплуатации. Поскольку содержимое кеша сохраняется после завершения HTTP-запроса, атака на кеш может раскрыть информацию еще долго после того, как пользователь считает, что информация была удалена из сети. Следовательно, содержимое кэша должно быть защищено как конфиденциальная информация.

В частности, различные атаки могут быть усилены хранением в общем кеше; такие атаки «cache poisoning» (отравления кэша) используют кэш для распределения вредоносной полезной нагрузки среди многих клиентов и особенно эффективны, когда злоумышленник может использовать недостатки реализации, повышенные привилегии или другие методы для вставки такого ответа в кэш. Одним из распространенных векторов атак для отравления кэша является использование различий в разборе сообщений на прокси и пользовательских агентах; см. раздел 3.3.3 [RFC7230 #] для соответствующих требований.

Аналогичным образом, недостатки реализации (а также неправильное понимание операции кеширования) могут привести к кешированию конфиденциальной информации (например, учетных данных для аутентификации), которая считается конфиденциальной, и раскрыть ее посторонним лицам.

Кроме того, само использование кэша может привести к проблемам конфиденциальности. Например, если два пользователя совместно используют кеш, а первый просматривает сайт, второй может обнаружить, что другой пользователь посещал этот сайт, поскольку ресурсы из него загружаются быстрее благодаря кешу.

Обратите внимание, что поле заголовка ответа Set-Cookie [RFC6265 #] не запрещает кэширование; кешируемый ответ с полем заголовка Set-Cookie может использоваться (и часто используется) для удовлетворения последующих запросов к кешу. Серверы, которые хотят контролировать кэширование этих ответов, должны выдавать соответствующие поля заголовка ответа Cache-Control.

 

9. Благодарности

См. Раздел 10 [RFC7230 #].

 

10. Ссылки

 

10.1. Нормативные ссылки

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, June 2014.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content», RFC 7231, June 2014.

[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests», RFC 7232, June 2014.

[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Range Requests», RFC 7233, June 2014.

[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Authentication», RFC 7235, June 2014.

 

10.2. Информационные ссылки

[BCP90] Klyne, G., Nottingham, M., and J. Mogul, «Registration Procedures for Message Header Fields», BCP 90, RFC 3864, September 2004.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5861] Nottingham, M., «HTTP Cache-Control Extensions for Stale Content», RFC 5861, April 2010.

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, «Network Time Protocol Version 4: Protocol and Algorithms Specification», RFC 5905, June 2010.

[RFC6265] Barth, A., «HTTP State Management Mechanism», RFC 6265, April 2011.

 

Приложение A. Изменения по сравнению с RFC 2616

Спецификация была существенно переписана для ясности.

Условия, при которых аутентифицированный ответ может быть кэширован, были уточнены. (Раздел 3.2)

Новые коды состояния теперь могут определять, что кэшам разрешено использовать эвристическую свежесть с ними. Теперь кэшам разрешено вычислять эвристическую свежесть для URI с компонентами запросов. (Раздел 4.2.2)

Алгоритм расчета возраста теперь менее консервативный. Теперь кэшам необходимо обрабатывать даты с часовыми поясами, как если бы они были недействительными, потому что невозможно точно угадать. (Раздел 4.2.3)

Поле заголовка ответа Content-Location больше не используется для определения подходящего ответа для использования при проверке. (Раздел 4.3)

Алгоритм выбора согласованного кешированного ответа на использование был разъяснен несколькими способами. В частности, теперь он явно разрешает канонизацию заголовка при обработке выбора полей заголовка. (Раздел 4.1)

Требования по предотвращению атак типа «отказ в обслуживании» при выполнении аннулирования были разъяснены. (Раздел 4.4)

Аннулирование кэша происходит только при получении успешного ответа. (Раздел 4.4)

Директивы Cache явно определены без учета регистра. Обработка нескольких экземпляров директив кэша, когда ожидается только один, теперь определена. (Раздел 5.2)

Директива запроса no-store не применяется к ответам; то есть, кеш может удовлетворить запрос без хранения и не делает его недействительным. (Раздел 5.2.1.5)

Отмечено, что квалифицированные формы директив кэша «private» и «no-cache» не получили широкого применения; например, «private = foo» во многих кешах интерпретируется как просто «private». Кроме того, значение уточненной формы no-cache было уточнено. (Раздел 5.2.2)

Значение директивы ответа «no-cache» разъяснено. (Раздел 5.2.2.2)

Годовой лимит значений поля заголовка Expires был удален; вместо этого приводится обоснование использования разумного значения. (Раздел 5.3)

Поле заголовка Pragma теперь определено только для обратной совместимости; будущие прагмы устарели. (Раздел 5.4)

Некоторые требования, касающиеся производства и обработки полей заголовка Warning, были ослаблены, поскольку они не получили широкого применения. Кроме того, поле заголовка Warning больше не использует кодировку RFC 2047 и не допускает использование нескольких языков, поскольку эти аспекты не были реализованы. (Раздел 5.5)

Эта спецификация вводит директивы «Cache Directive» и реестры «Warn Code» и определяет соображения относительно новых директив кэша. (Раздел 7.1 и Раздел 7.2)

 

Приложение B. Импортированный ABNF

Следующие основные правила включены посредством ссылки, как определено в Приложении B.1 [RFC5234 #]: ALPHA (буквы), CR (возврат каретки), CRLF (CR LF), CTL (элементы управления), DIGIT (десятичное 0-9) , DQUOTE (двойная кавычка), HEXDIG (шестнадцатеричный 0-9 / A-F / a-f), LF (перевод строки), OCTET (любая 8-битная последовательность данных), SP (пробел) и VCHAR (любой видимый символ US-ASCII ).

Правила ниже определены в [RFC7230 #]:

OWS = <OWS, смотри [RFC7230 #], Раздел 3.2.3>
field-name = <field-name, смотри [RFC7230 #], Раздел 3.2>
quoted-string = <quoted-string, смотри [RFC7230 #], Раздел 3.2.6>

token = <token, смотри [RFC7230 #], Раздел 3.2.6>
port = <port, смотри [RFC7230 #], Раздел 2.7>
pseudonym = <pseudonym, смотри [RFC7230 #], Раздел 5.7.1>
uri-host = <uri-host, смотри [RFC7230 #], Раздел 2.7>

Правила ниже определены в других частях:

HTTP-date = <HTTP-date, смотри [RFC7231 #], Раздел 7.1.1.1>

 

Приложение C. Собранный ABNF

В приведенной ниже ABNF правила списка расширены в соответствии с разделом 1.2 [RFC7230 #].

Age = delta-seconds

Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS cache-directive ] )

Expires = HTTP-date

HTTP-date = <HTTP-date, смотри [RFC7231 #], Раздел 7.1.1.1>

OWS = <OWS, смотри [RFC7230 #], Раздел 3.2.3>

Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS pragma-directive ] )

Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] )

cache-directive = token [ "=" ( token / quoted-string ) ]

delta-seconds = 1*DIGIT

extension-pragma = token [ "=" ( token / quoted-string ) ]

field-name = <field-name, смотри [RFC7230 #], Раздел 3.2>

port = <port, смотри [RFC7230 #], Раздел 2.7>
pragma-directive = "no-cache" / extension-pragma
pseudonym = <pseudonym, смотри [RFC7230 #], Раздел 5.7.1>

quoted-string = <quoted-string, смотри [RFC7230 #], Раздел 3.2.6>

token = <token, смотри [RFC7230 #], Раздел 3.2.6>

uri-host = <uri-host, смотри [RFC7230 #], Раздел 2.7>

warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-code = 3DIGIT
warn-date = DQUOTE HTTP-date DQUOTE
warn-text = quoted-string
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date ]

Индекс

1

110 (warn-code) 31
111 (warn-code) 31
112 (warn-code) 31
113 (warn-code) 31
199 (warn-code) 32

2

214 (warn-code) 32
299 (warn-code) 32

A

age 11
Age header field 21

C

cache 4
cache entry 5
cache key 5-6
Cache-Control header field 21

D

Disconnected Operation (warn-text) 31

E

Expires header field 28
explicit expiration time 11

F

fresh 11
freshness lifetime 11

G

Grammar

Age 21
Cache-Control 22
cache-directive 22
delta-seconds 5
Expires 28
extension-pragma 29
Pragma 29
pragma-directive 29
warn-agent 29
warn-code 29
warn-date 29
warn-text 29
Warning 29
warning-value 29

H

Heuristic Expiration (warn-text) 31
heuristic expiration time 11

M

max-age (cache directive) 22, 26
max-stale (cache directive) 22
min-fresh (cache directive) 22
Miscellaneous Persistent Warning (warn-text) 32
Miscellaneous Warning (warn-text) 32
must-revalidate (cache directive) 24

N

no-cache (cache directive) 23, 25
no-store (cache directive) 23, 24
no-transform (cache directive) 23, 25

O

only-if-cached (cache directive) 23

P

Pragma header field 29
private (cache directive) 25
private cache 4
proxy-revalidate (cache directive) 26
public (cache directive) 25

R

Response is Stale (warn-text) 30
Revalidation Failed (warn-text) 31

S

s-maxage (cache directive) 27
shared cache 4
stale 11
strong validator 18

T

Transformation Applied (warn-text) 32

V

validator 16

W

Warning header field 29

Адреса авторов

Roy T. Fielding (editor)
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
USA
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/

Mark Nottingham (editor)
Akamai
EMail: mnot@mnot.net
URI: http://www.mnot.net/

Julian F. Reschke (editor)
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/