Эта страница переведена с помощью Cloud Translation API.

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

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

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

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

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

Примечание. Использование заголовков для влияния на ключи кэша и TTL записи кэша. Edge может использовать заголовки ответов при создании ключей кэша ответов и настройке TTL записи кэша. Для этого вы используете следующие элементы флагов политики ResponseCache:

<UseResponseCacheHeaders> — если для этого параметра установлено значение true , Edge будет учитывать заголовки ответа HTTP, используемые при настройке «времени жизни» (TTL) ответа в кеше. Дополнительные сведения см. в разделах «Настройка срока действия записи кэша» и <UseResponseCacheHeaders> в политике кэша ответов .
<UseAcceptHeader> — если для этого параметра установлено значение true , Edge будет использовать заголовки Accept ответа для увеличения ключа кэша. Дополнительные сведения см. в разделе <UseAcceptHeader> в политике кэша ответов .

Заголовок	Поддерживать
Кэш-Контроль	Поддерживается для ответов, возвращаемых с исходных серверов, но не для клиентских запросов. Edge поддерживает подмножество директив.
Срок действия истекает	Поддерживается. Можно переопределить.
Теги объектов (ETags)	Особое поведение для If-Match и If-None-Match .
Если-Изменено-С тех пор	При запросах GET заголовок передается на исходный сервер, даже если существует действительная запись в кэше.
Принять-кодирование	Edge отправляет сжатые или несжатые ответы в зависимости от входящих заголовков.

Кэш-Контроль

Apigee Edge поддерживает заголовок Cache-Control только в ответах, возвращаемых с исходных серверов (спецификация HTTP/1.1 разрешает использовать заголовки Cache-Control как в запросах клиента, так и в ответах исходного сервера). Исходные серверы могут включать как целевые конечные точки, определенные в прокси-сервере Apigee Edge API, так и созданные с помощью вызовов 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 для ответов от исходных серверов. В следующей таблице описана поддержка Apigee Edge для директив заголовка ответа HTTP Cache-Control.

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

Директива Cache-Control	Как Apigee Edge обрабатывает директиву
`cache-extension`	Не поддерживается.
`max-age`	Если ваша политика ResponseCache устанавливает для элемента `<UseResponseCacheHeaders>` значение `true` , ответ может быть кэширован на количество секунд, указанное этой директивой. Эта директива переопределяется директивой `s-maxage` и переопределяет заголовок `Expires` . Его также можно переопределить с помощью элемента `<ExpirySettings>` политики. Дополнительные сведения см. в разделах «Настройка срока действия записи кэша» и `<UseResponseCacheHeaders>` в политике кэша ответов . Примечание. Содержимое, кэшированное с помощью политики ResponseCache, сохранит значение максимального возраста, установленное его источником. Это означает, что при извлечении из кэша контент может быть старше, чем предполагает его значение максимального возраста (старше, чем знает клиент).
`must-revalidate`	Не поддерживается. Все записи кэша удаляются Apigee Edge по истечении срока их действия.
`no-cache`	Edge кэширует исходный ответ, но его необходимо повторно проверить на исходном сервере, прежде чем использовать для удовлетворения любых последующих клиентских запросов. Это правило позволяет источнику возвращать ответ 304 Not Modified, чтобы указать, что ответ должен быть возвращен из кэша, тем самым сохраняя обработку, необходимую для возврата всего ответа. Если исходный сервер возвращает полный ответ, он заменяет существующую запись в кэше. Любые имена полей, указанные в этой директиве, игнорируются. Примечание. Заголовок HTTP/1.0 `Pragma: no-cache` рассматривается как эквивалент `Cache-Control: no-cache` .
`no-store`	Не поддерживается.
`no-transform`	Не поддерживается.
`private`	Не поддерживается. Если эта директива получена, исходный ответ не кэшируется. Любые имена полей игнорируются.
`proxy-revalidate`	Не поддерживается. Все записи кэша удаляются Apigee Edge по истечении срока их действия.
`public`	Edge кэширует исходный ответ, даже если другие директивы указывают иное. Согласно спецификации HTTP/1.1, единственное исключение из этого правила — это случаи, когда ответ включает заголовок авторизации.
`s-maxage`	Если ваша политика ResponseCache устанавливает для элемента `<UseResponseCacheHeaders>` значение `true` , ответ может быть кэширован на количество секунд, указанное этой директивой. Эта директива переопределяет директиву `max-age` и заголовок `Expires` . Его можно переопределить с помощью элемента `<ExpirySettings>` политики. Дополнительные сведения см. в разделах «Настройка срока действия записи кэша» и `<UseResponseCacheHeaders>` в политике кэша ответов . Примечание. Содержимое, кэшированное с помощью политики ResponseCache, сохранит значение s-maxage, установленное его источником. Это означает, что при извлечении из кэша содержимое может быть старше, чем предполагает его значение s-maxage (старше, чем знает клиент).

Срок действия истекает

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

Примечание. Директивы заголовка Cache-Control max-age и s-maxage имеют приоритет над заголовком Expires и переопределяют его. Дополнительные сведения см. в разделах «Настройка срока действия записи кэша» и <UseResponseCacheHeaders> в политике кэша ответов .

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

Истекает: четверг, 01 декабря 1994 г., 16:00:00 по Гринвичу.

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

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

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

ETag

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

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

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

Если-Матч

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

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

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

Если	Затем
Заголовок `If-Match` указывает один или несколько тегов ETag.	Apigee Edge извлекает все записи кэша с истекшим сроком действия для указанного ресурса и сравнивает все надежные теги ETag в этих кэшированных записях с теми, которые указаны в заголовке `If-Match` . Если совпадение найдено, возвращается запись кэша. Если нет, запрос передается на исходный сервер.
Заголовок `If-Match` указывает «*».	Запрос передается на исходный сервер, чтобы гарантировать, что все средства кэширования источника смогут обработать запрос.
Обнаружена запись в кэше с тем же URI запроса, но она содержит только слабые ETags.	Запись должна быть повторно проверена исходным сервером перед возвратом клиенту.
ETags поступает с исходного сервера.	ETag возвращается клиенту без изменений.

Если-Нет-Матча

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

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

Если	Затем
Заголовок `If-None-Match` указывает один или несколько тегов ETag.	Apigee Edge извлекает все записи кэша с истекшим сроком действия для указанного URI и сравнивает все надежные теги ETag в этих кэшированных записях с теми, которые указаны в заголовке `If-None-Match` . Если совпадение найдено, Edge возвращает статус 304 Not Modified. Если совпадение не найдено, Edge передает запрос на исходный сервер.
В заголовке `If-None-Match` указан «*», и существует кэшированная запись с истекшим сроком действия для запрошенного URI.	Edge возвращает статус 304 «Не изменено».
Обнаружена запись кэша с тем же URI запроса, но содержит только слабые ETags.	Запись должна быть повторно проверена исходным сервером, прежде чем Edge вернет ее клиенту.
Edge получает ETag от исходного сервера	ETag возвращается клиенту без изменений.

Если-Изменено-С тех пор

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

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

Принять-кодирование

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

Вы можете добавить значения заголовка Accept к ключам кэша, чтобы сделать ключи более значимыми для каждого кэшированного элемента. Дополнительные сведения см. в разделе «Настройка ключа кэша» в политике кэширования ответов .