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

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

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

В этой теме описывается, как 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-запросов заголовок передается на исходный сервер, даже если существует действительная запись в кэше.
Accept-Encoding	В зависимости от входящих заголовков Edge отправляет либо сжатые, либо несжатые ответы.

Управление кэшем

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

Ограничения поддержки управления кэшем

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.

Директива управления кэшем	Как Apigee Edge обрабатывает директиву
`cache-extension`	Не поддерживается.
`max-age`	Если в вашей политике ResponseCache элемент `<UseResponseCacheHeaders>` установлен в `true` , ответ может быть кэширован в течение количества секунд, указанного в этой директиве. Эта директива переопределяется директивой `s-maxage` и переопределяет заголовок `Expires` . Она также может быть переопределена элементом `<ExpirySettings>` политики. Для получения дополнительной информации см. раздел «Установка срока действия записи в кэше» и `<UseResponseCacheHeaders>` в политике кэширования ответов . Примечание: Содержимое, кэшированное с использованием политики ResponseCache, будет сохранять значение max-age, установленное источником. Это означает, что при извлечении из кэша содержимое может быть старше, чем предполагает значение max-age (старше, чем известно клиенту).
`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, единственным исключением из этого правила является наличие в ответе заголовка Authorization.
`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 GMT

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

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

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

ETag

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

Когда целевая конечная точка отправляет ответ в 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` указывает один или несколько ETags.	Apigee Edge извлекает все непросроченные записи кэша для указанного ресурса и сравнивает все сильные ETag-теги этих кэшированных записей с ETag-тегами, указанными в заголовке `If-Match` . Если совпадение найдено, возвращается запись из кэша. В противном случае запрос передается на исходный сервер.
В заголовке `If-Match` указано «*»	Запрос передается на исходный сервер, чтобы гарантировать, что все кэширующие средства исходного сервера смогут его обработать.
Обнаружена запись в кэше с тем же URI запроса, но она содержит только слабые ETags.	Перед возвратом клиенту запись должна быть повторно проверена исходным сервером.
Электронные теги (ETags) поступают с исходного сервера.	ETag возвращается клиенту без изменений.

Если совпадений нет

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

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

Если	Затем
Заголовок `If-None-Match` указывает один или несколько ETags.	Apigee Edge извлекает все непросроченные записи кэша для указанного URI и сравнивает все сильные ETag-теги этих кэшированных записей с 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

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

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