Cette page a été traduite par l'API Cloud Translation.

Compatibilité avec les en-têtes de réponse HTTP

Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation sur Apigee X. info

Cet article explique comment Edge gère les en-têtes de mise en cache HTTP/1.1 lorsque vous utilisez la règle ResponseCache. Apigee Edge est actuellement compatible avec un sous-ensemble d'en-têtes et d'instructions de mise en cache HTTP/1.1 (les fonctionnalités non compatibles sont répertoriées dans cette rubrique) provenant des serveurs (d'origine) cibles backend.

De plus, avec certains en-têtes, Edge prend les mesures nécessaires en fonction de leurs instructions. Dans certains cas, ces en-têtes de mise en cache HTTP/1.1 remplacent le comportement spécifié dans la règle ResponseCache. Par exemple, si l'en-tête Cache-Control est renvoyé par un serveur backend, vous pouvez demander à la directive s-maxage de l'en-tête de remplacer d'autres paramètres d'expiration dans la règle.

Remarque:En utilisant des en-têtes pour influencer les clés de cache et la valeur TTL d'entrée du cache, Edge peut utiliser des en-têtes de réponse lors de la création des clés de cache de réponse et de la définition de la valeur TTL d'entrée du cache. Pour ce faire, vous utilisez les éléments d'option suivants de la règle ResponseCache :

<UseResponseCacheHeaders> : lorsque cet élément est défini sur true, Edge prend en compte les en-têtes de réponse HTTP utilisés pour définir la valeur TTL (Time To Live) de la réponse dans le cache. Pour en savoir plus, consultez la section "Définir le délai d'expiration des entrées de cache" et <UseResponseCacheHeaders> dans la Règle de réponse du cache.
<UseAcceptHeader> : lorsque cet élément est défini sur true, Edge utilise des en-têtes de réponse Accept pour augmenter la clé de cache. Pour en savoir plus, consultez la section <UseAcceptHeader> dans la Règle de réponse du cache.

En-tête	Assistance
Cache-Control	Compatible avec les réponses renvoyées par les serveurs d'origine backend, mais pas avec les requêtes client. Edge est compatible avec un sous-ensemble d'instructions.
Expiration	Compatible Peut être ignoré
Tags d'entité (ETags)	Comportement spécifique pour If-Match et If-None-Match.
If-Modified-Since	Pour les requêtes GET, l'en-tête est transmis au serveur d'origine même si une entrée de cache valide existe.
Accept-Encoding	Edge envoie des réponses compressées ou non compressées en fonction des en-têtes entrants.

Cache-Control

Apigee Edge n'accepte l'en-tête Cache-Control que sur les réponses renvoyées par les serveurs d'origine du backend (la spécification HTTP/1.1 autorise les en-têtes Cache-Control dans les requêtes client et dans les réponses du serveur d'origine). Les serveurs d'origine peuvent inclure à la fois les points de terminaison cibles définis dans un proxy d'API Apigee Edge, et ceux créés à l'aide d'appels d'API TargetServer.

Limites de compatibilité de Cache-Control

Apigee Edge est compatible avec un sous-ensemble de fonctionnalités d'en-tête de réponse Cache-Control défini dans la spécification HTTP/1.1. Remarques :

Apigee Edge n'accepte pas les en-têtes Cache-Control qui arrivent avec des requêtes client entrantes.
Apigee Edge n'est compatible qu'avec la notion de cache public. (D'après la spécification HTTP, Cache-Control peut être public (partagé) ou privé (utilisateur unique).
Apigee Edge n'accepte qu'un sous-ensemble d'instructions de réponse Cache-Control dans la spécification HTTP/1.1. Pour en savoir plus, consultez la section Compatibilité avec les instructions d'en-tête de réponse Cache-Control.

Compatibilité avec les instructions d'en-tête de réponse Cache-Control

Apigee est compatible avec des instructions d'un sous-ensemble issu de la spécification HTTP/1.1 pour les réponses des serveurs d'origine. Le tableau suivant décrit la compatibilité d'Apigee Edge avec les instructions d'en-tête de réponse Cache-Control HTTP.

Pour en savoir plus sur les instructions répertoriées dans cette partie, consultez la section Cache-Control dans la spécification HTTP/1.1.

Instruction Cache-Control	Comment Apigee Edge traite la directive
`cache-extension`	Non compatible.
`max-age`	Si votre règle ResponseCache définit l'élément `<UseResponseCacheHeaders>` sur `true`, la réponse peut être mise en cache pendant le nombre de secondes spécifié par cette instruction. Cette instruction est remplacée par l'instruction `s-maxage` et remplace l'en-tête `Expires`. Elle peut également être remplacée par l'élément `<ExpirySettings>` de la règle. Pour en savoir plus, consultez la section "Définir le délai d'expiration des entrées de cache" et `<UseResponseCacheHeaders>` dans la Règle de réponse du cache. Remarque : Le contenu mis en cache à l'aide de la règle ResponseCache conserve la valeur max-age définie par son origine. Cela signifie que lorsqu'il est récupéré à partir du cache, le contenu peut être antérieur à sa valeur max-age que ce qui est suggéré (soit plus ancien que ce que le client croit).
`must-revalidate`	Non compatible. Toutes les entrées de cache sont supprimées par Apigee Edge dès leur expiration.
`no-cache`	Edge met en cache la réponse d'origine, mais celle-ci doit être à nouveau validée avec le serveur d'origine avant d'être utilisée pour répondre aux requêtes suivantes de l'utilisateur. Cette règle permet à l'origine de renvoyer une réponse 304 Not Modified afin d'indiquer que la réponse doit être renvoyée à partir du cache, et enregistre ainsi le traitement nécessaire pour la renvoyer dans son intégralité. Si le serveur d'origine renvoie une réponse complète, il remplace l'entrée de cache existante. Tous les noms de champs spécifiés avec cette instruction sont ignorés. Remarque : L'en-tête HTTP/1.0 `Pragma: no-cache` est traité de la même façon que `Cache-Control: no-cache`.
`no-store`	Non compatible.
`no-transform`	Non compatible.
`private`	Non compatible. Si cette instruction est reçue, la réponse d'origine n'est pas mise en cache. Tous les noms de champs sont ignorés.
`proxy-revalidate`	Non compatible. Toutes les entrées de cache sont supprimées par Apigee Edge dès leur expiration.
`public`	Edge met en cache la réponse d'origine, même si d'autres instructions indiquent d'autres réponses. Conformément à la spécification HTTP/1.1, la seule exception à cette règle s'applique lorsque la réponse inclut un en-tête d'autorisation.
`s-maxage`	Si votre règle ResponseCache définit l'élément `<UseResponseCacheHeaders>` sur `true`, la réponse peut être mise en cache pendant le nombre de secondes spécifié par cette instruction. Cette instruction remplace l'instruction `max-age` et l'en-tête `Expires`. Elle peut être remplacée par l'élément `<ExpirySettings>` de la règle. Pour en savoir plus, consultez la section "Définir le délai d'expiration des entrées de cache" et `<UseResponseCacheHeaders>` dans la Règle de réponse du cache. Remarque : Le contenu mis en cache à l'aide de la règle ResponseCache conserve la valeur s-maxage définie par son origine. Cela signifie que lorsqu'il est récupéré à partir du cache, le contenu peut être antérieur à sa valeur s-maxage que ce qui est suggéré (soit plus ancien que ce que le client croit).

Expiration

Lorsque l'option UseResponseCacheHeaders de la règle ResponseCache est définie sur true, Edge peut utiliser l'en-tête Expires pour déterminer la valeur TTL (Time To Live) d'une entrée en cache. Cet en-tête spécifie une date et une heure après lesquelles l'entrée du cache d'une réponse est considérée comme obsolète. Cet en-tête permet aux serveurs de signaler à quel moment vous pouvez renvoyer une valeur mise en cache en fonction d'un horodatage.

Remarque : Les instructions d'en-tête Cache-Control max-age et s-maxage prévalent et remplacent la valeur Expires. Pour en savoir plus, consultez la section "Définir le délai d'expiration des entrées de cache" et <UseResponseCacheHeaders> dans la Règle de réponse du cache.

Les formats de date compatibles avec l'en-tête Expires sont décrits dans la spécification HTTP/1.1. Exemple :

Date d'expiration : 1er décembre 1994 16:00:00 GMT

Pour plus d'informations sur les formats de date et d'heure HTTP, consultez la section Formats de date/heure dans la spécification HTTP/1.1.

Remarque : Bien que la section 14.21 de la spécification indique qu'une valeur Expires supérieure à un an dans le futur signifie qu'une entrée de cache n'expire jamais, Apigee interprète cette valeur comme signifiant que l'entrée doit être mise en cache avant la date et l'heure spécifiées.

Pour en savoir plus sur l'en-tête Expires, consultez la section Définitions des champs d'en-tête dans la spécification HTTP/1.1.

ETag

Un tag d'entité (ETag) est un identifiant associé à une ressource demandée. À l'aide d'un ETag, un serveur peut déterminer si la ressource demandée et la ressource mise en cache associée correspondent. Par exemple, le serveur peut remettre en cache la réponse si elle ne correspond pas à celle actuellement mise en cache. Il peut renvoyer la ressource mise en cache si les ETag correspondent.

Lorsqu'un point de terminaison cible renvoie une réponse à Edge avec un ETag, Edge met en cache l'ETag avec la réponse.

Pour en savoir plus sur les tags d'entité, consultez la section Paramètres de protocole dans la spécification HTTP/1.1.

If-Match

Avec l'en-tête de requête If-Match, une entité mise en cache est actuelle si l'ETag de l'en-tête correspond à l'ETag mis en cache. Toute requête autre que GET qui spécifie un en-tête If-Match est transmise au serveur d'origine pour s'assurer que les installations de mise en cache d'origine ont la possibilité de traiter la requête.

Pour en savoir plus sur If-Match, consultez la section Définitions des champs d'en-tête dans la spécification HTTP/1.1.

Si Edge reçoit une requête GET entrante d'un client qui inclut un en-tête If-Match:

Si	Dans ce cas
L'en-tête `If-Match` spécifie un ou plusieurs ETags.	Apigee Edge récupère toutes les entrées de cache non expirées pour la ressource spécifiée et compare les ETags forts sur ces entrées mises en cache à celles spécifiées dans l'en-tête `If-Match`. Si une correspondance est trouvée, l'entrée du cache est renvoyée. Dans le cas contraire, la requête est transmise au serveur d'origine.
L'en-tête `If-Match` indique le signe "*".	La requête est transmise au serveur d'origine afin de garantir que les installations de mise en cache d'origine ont la possibilité de la traiter.
Une entrée de cache avec le même URI de requête est trouvée, mais elle ne contient que des ETags faibles.	L'entrée doit être revalidée par le serveur d'origine avant d'être renvoyée au client.
Les ETags proviennent du serveur d'origine.	L'ETag est renvoyé inchangé au client.

If-None-Match

Avec l'en-tête If-None-Match, une entité mise en cache est actuelle si l'ETag de l'en-tête ne correspond pas à l'ETag mis en cache. Les requêtes autres que GET contenant cet en-tête sont transmises au serveur d'origine.

Si Edge reçoit une requête GET entrante avec cet en-tête:

Si	Dans ce cas
L'en-tête `If-None-Match` spécifie un ou plusieurs ETags.	Apigee Edge récupère toutes les entrées de cache non expirées pour l'URI spécifié et compare les ETags forts sur ces entrées mises en cache à celles spécifiées dans l'en-tête `If-None-Match`. Si une correspondance est trouvée, Edge renvoie l'état "304 Not Modified". Si aucune correspondance n'est trouvée, Edge transmet la requête au serveur d'origine.
L'en-tête `If-None-Match` spécifie le signe "*" et une entrée mise en cache non expirée pour l'URI demandé existe.	Edge renvoie un état "304 Not Modified".
Une entrée de cache avec le même URI de requête est trouvée, mais elle ne contient que des ETag faibles.	L'entrée doit être revalidée par le serveur d'origine avant qu'Edge ne la renvoie au client.
Edge reçoit un ETag d'un serveur d'origine.	L'ETag est renvoyé inchangé au client.

If-Modified-Since

Si Apigee Edge reçoit un en-tête If-Modified-Since dans une requête GET, il est transmis au serveur d'origine même si une entrée de cache valide existe.

Cela garantit que toutes les mises à jour d'une ressource qui n'ont pas été transmises via Apigee Edge sont prises en compte. Si le serveur d'origine renvoie une nouvelle entité, Edge remplace l'entrée de cache existante par la nouvelle valeur. Si le serveur renvoie un état "304 Not modified", Edge renvoie la valeur de la réponse si l'en-tête Last-Modified de la réponse mise en cache indique qu'elle n'a pas été modifiée.

Accept-Encoding

Lorsqu'une requête entrante inclut l'en-tête Accept-Encoding avec les valeurs gzip, deflate ou compress, le serveur d'origine répond avec des données compressées. Lorsque les requêtes suivantes ne contiennent pas les en-têtes Accept-Encoding, elles attendent une réponse non compressée. Le mécanisme de mise en cache de réponses d'Apigee est capable d'envoyer des réponses compressées et non compressées en fonction des en-têtes entrants sans revenir au serveur d'origine.

Vous pouvez ajouter des valeurs d'en-tête "Accept" aux clés du cache pour améliorer la pertinence des clés pour chaque élément mis en cache. Pour en savoir plus, consultez la section "Configurer une clé de cache" dans la Règle de réponse du cache.