Поддержка заголовков HTTP-ответов

Вы просматриваете документацию по Apigee Edge.
Перейдите к документации по Apigee X. Информация

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

Кроме того, Edge выполняет действия на основе директив в некоторых заголовках. В некоторых случаях эти заголовки кеша HTTP/1.1 переопределяют поведение, заданное в правиле ResponseCache. Например, если заголовок Cache-Control возвращается с внутреннего сервера, директива s-maxage в заголовке может переопределить другие настройки срока действия в правилах.

Заголовок Поддержка
Cache-Control Поддерживается в ответах, возвращаемых исходными серверами, но не в клиентских запросах. Edge поддерживает только некоторые директивы.
Срок действия Поддерживаются. Можно переопределить.
Теги объектов (ETag) Особые правила для заголовков If-Match и If-None-Match.
If-Modified-Since В запросах GET заголовок передается на сервер-источник, даже если существует действительная запись в кеше.
Accept-Encoding Edge отправляет сжатые или несжатые ответы в зависимости от входящих заголовков.

Cache-Control

Apigee Edge поддерживает заголовок Cache-Control только в ответах, возвращаемых серверами-источниками (спецификация HTTP/1.1 разрешает заголовки Cache-Control как в запросах клиентов, так и в ответах серверов-источников). Серверы-источники могут включать как целевые конечные точки, определенные в прокси-сервере API Apigee Edge, так и созданные с помощью вызовов API TargetServer.

Ограничения поддержки Cache-Control

Apigee Edge поддерживает подмножество возможностей заголовка ответа Cache-Control, определенных в спецификации HTTP/1.1. Обратите внимание на следующее:

  • Apigee Edge не поддерживает заголовки Cache-Control, которые поступают с входящими клиентскими запросами.
  • Apigee Edge поддерживает только общедоступные кеши. (Согласно спецификации HTTP, Cache-Control может быть общедоступным или частным.)
  • Apigee Edge поддерживает только часть директив ответа Cache-Control в спецификации HTTP/1.1. Подробнее о поддержке директив заголовка ответа Cache-Control…

Поддержка директив заголовка ответа Cache-Control

Apigee поддерживает подмножество директив из спецификации HTTP/1.1 в ответах от исходных серверов. В таблице ниже описана поддержка директив заголовка ответа HTTP Cache-Control в Apigee Edge.

Более подробную информацию о перечисленных здесь директивах можно найти в разделе Cache-Control спецификации HTTP/1.1.

Директива Cache-Control Как Apigee Edge обрабатывает директиву
cache-extension Не поддерживается.
max-age

Если в правилах ResponseCache для элемента <UseResponseCacheHeaders> указано значение true, ответ можно кэшировать на количество секунд, указанное в этой директиве.

Эта директива переопределяется директивой s-maxage и переопределяет заголовок Expires. Его также можно переопределить с помощью элемента <ExpirySettings> в правиле. Подробнее о том, как задать срок действия записи в кеше и <UseResponseCacheHeaders>…
must-revalidate Не поддерживается. Все записи кеша удаляются Apigee Edge сразу после истечения срока их действия.
no-cache

Пограничный кеш сохраняет ответ сервера-источника, но перед тем, как использовать его для обработки последующих клиентских запросов, он должен быть повторно проверен на сервере-источнике. Это правило позволяет источнику возвращать ответ 304 Not Modified (Не изменено), чтобы указать, что ответ должен быть возвращен из кеша, тем самым экономя ресурсы, необходимые для возврата всего ответа. Если сервер-источник возвращает полный ответ, он заменяет существующую запись в кеше. Все имена полей, указанные в этой директиве, игнорируются.
no-store Не поддерживается.
no-transform Не поддерживается.
private Не поддерживается. Если получена эта директива, ответ источника не кешируется. Названия полей игнорируются.
proxy-revalidate Не поддерживается. Все записи кеша удаляются Apigee Edge сразу после истечения срока их действия.
public Edge кеширует ответ источника, даже если другие директивы указывают на обратное. Согласно спецификации HTTP/1.1, единственное исключение из этого правила – если ответ содержит заголовок Authorization.
s-maxage

Если в правилах ResponseCache для элемента <UseResponseCacheHeaders> указано значение true, ответ можно кэшировать на количество секунд, указанное в этой директиве.

Эта директива переопределяет директиву max-age и заголовок Expires. Его можно переопределить с помощью элемента <ExpirySettings> правила. Подробнее о том, как задать срок действия записи в кеше и <UseResponseCacheHeaders>…

Окончание действия:

Если флаг UseResponseCacheHeaders в правиле ResponseCache имеет значение true, Edge может использовать заголовок Expires, чтобы определить время жизни (TTL) кешированной записи. Этот заголовок указывает дату и время, после которых запись в кеше ответа считается устаревшей. Этот заголовок позволяет серверам указывать, когда можно возвращать кешированное значение на основе временной метки.

Допустимые форматы даты для заголовка Expires описаны в спецификации HTTP/1.1. Пример:

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

Подробную информацию о форматах даты и времени HTTP можно найти в разделе Форматы даты и времени спецификации HTTP/1.1.

Подробнее о заголовке Expires можно узнать в разделе Определения полей заголовка спецификации HTTP/1.1.

ETag

Тег объекта (ETag) – это идентификатор, связанный с запрошенным ресурсом. С помощью тега ETag сервер может определить, совпадают ли запрошенный ресурс и связанный с ним кешированный ресурс. Например, сервер может повторно кешировать ответ, если он не соответствует тому, что уже есть в кеше. Если теги ETag совпадают, он может вернуть кешированный ресурс.

Когда целевая конечная точка отправляет ответ обратно в Edge с тегом ETag, Edge кеширует тег ETag вместе с ответом.

Подробнее о тегах объектов можно прочитать в разделе Параметры протокола спецификации HTTP/1.1.

If-Match

Если в запросе есть заголовок запроса If-Match, то кешированный объект считается актуальным, если значение ETag в заголовке совпадает с кешированным значением ETag. Любые запросы, кроме GET, в которых указан заголовок If-Match, передаются на сервер-источник, чтобы у исходных кеширующих средств была возможность обработать запрос.

Подробнее о If-Match можно прочитать в разделе Header Field Definitions спецификации HTTP/1.1.

Если Edge получает входящий GET-запрос от клиента, который включает заголовок If-Match:

Для поддержки Затем
Заголовок If-Match содержит один или несколько тегов ETag.
  1. Apigee Edge извлекает все записи кеша с неистекшим сроком действия для указанного ресурса и сравнивает все строгие теги ETag в этих записях кеша с тегами, указанными в заголовке If-Match.
  2. Если совпадение найдено, возвращается запись из кеша.
  3. Если нет, запрос передается на сервер-источник.
В заголовке If-Match указан символ "*". Запрос передается на сервер-источник, чтобы все средства кеширования сервера-источника могли обработать запрос.
В кеше найден объект с тем же URI запроса, но в нем содержатся только слабые теги ETag. Запись должна быть повторно проверена сервером-источником, прежде чем она будет возвращена клиенту.
Теги ETag поступают с сервера-источника. Тег ETag возвращается клиенту без изменений.

If-None-Match

При наличии заголовка If-None-Match кешированный объект считается актуальным, если значение ETag в заголовке не совпадает с кешированным значением ETag. Запросы, отличные от GET, содержащие этот заголовок, передаются на сервер-источник.

Если Edge получает входящий GET-запрос с этим заголовком:

Для поддержки Затем
Заголовок If-None-Match содержит один или несколько тегов ETag.
  1. Apigee Edge извлекает все неистекшие записи кеша для указанного URI и сравнивает все строгие теги ETag в этих записях с тегами, указанными в заголовке If-None-Match.
  2. Если совпадение найдено, Edge возвращает статус 304 Not Modified. Если совпадение не найдено, Edge передает запрос на сервер-источник.

Заголовок If-None-Match содержит символ "*", и для запрошенного URI существует запись в кеше, срок действия которой не истек.

 Edge возвращает статус 304 Not Modified
В кеше найден объект с тем же URI запроса, но он содержит только слабые теги ETag. Сервер происхождения должен заново проверить запись, прежде чем Edge вернет ее клиенту.
Пограничный сервер получает тег ETag от сервера-источника Тег ETag возвращается клиенту без изменений.

If-Modified-Since

Если Apigee Edge получает заголовок If-Modified-Since в GET-запросе, он передается на сервер-источник, даже если существует действительная запись в кеше.

Это позволяет учитывать все изменения ресурса, которые не были внесены через Apigee Edge. Если сервер-источник возвращает новый объект, Edge заменяет существующую запись в кеше новым значением. Если сервер возвращает статус 304 Not Modified (Не изменялось), Edge возвращает значение ответа, если заголовок Last-Modified в кешированном ответе указывает, что он не изменился.

Accept-Encoding

Если входящий запрос содержит заголовок Accept-Encoding со значениями gzip, deflate или compress, сервер-источник отвечает сжатыми данными. Если последующие запросы не содержат заголовки Accept-Encoding, то ожидается несжатый ответ. Механизм кеширования ответов Apigee может отправлять как сжатые, так и несжатые ответы в зависимости от входящих заголовков, не обращаясь к серверу-источнику.

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