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.
Consultez la documentation Apigee X. en savoir plus

Cette rubrique décrit comment Edge gère les en-têtes HTTP/1.1 de mise en cache lorsque vous utilisez la stratégie ResponseCache. Apigee Edge est actuellement compatible avec un sous-ensemble des en-têtes et des directives de mise en cache HTTP/1.1 (les fonctionnalités non compatibles sont répertoriées dans cette rubrique) reçus des serveurs cibles (origine) backend.

De plus, avec certains en-têtes, Edge effectue des actions en fonction de ses directives. 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:Utilisation d'en-têtes pour influencer les clés de cache et la valeur TTL des entrées de cache Vous pouvez demander à Edge d'utiliser des en-têtes de réponse lors de la construction des clés de cache de réponse et de la définition de la valeur TTL des entrées de cache. Pour ce faire, vous utilisez les éléments d'option suivants de la règle ResponseCache :

<UseResponseCacheHeaders> : lorsque cette valeur est définie sur true, Edge prend en compte les en-têtes de réponse HTTP utilisés lors de la définition de 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 ce paramètre est défini sur true, Edge utilise les en-têtes de réponse Accept pour étendre 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 prend en charge un sous-ensemble de directives.
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 prend en charge l'en-tête Cache-Control uniquement pour 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 les réponses du serveur d'origine). Les serveurs d'origine peuvent inclure à la fois des 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 des fonctionnalités d'en-tête de réponse Cache-Control définies 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 caches publics. (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 directives d'en-tête de réponse HTTP Cache-Control.

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 qu'elles expirent.
`no-cache`	Edge met en cache la réponse de l'origine, mais elle doit être revalidée avec le serveur d'origine avant d'être utilisée pour répondre à toute requête client ultérieure. 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 considéré comme équivalent à `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 qu'elles expirent.
`public`	Edge met en cache la réponse d'origine, même lorsque d'autres directives indiquent le contraire. 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).

Expire

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 mise 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 située plus d'un an dans le futur signifie qu'une entrée de cache n'expire jamais, Apigee interprète cette valeur comme indiquant que l'entrée doit être mise en cache jusqu'à 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 demande GET entrante d'un client qui comprend 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 les entrées de cache non expirées pour la ressource spécifiée et compare les ETag forts de ces entrées mises en cache à ceux spécifiés 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 demande 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 ETag forts de ces entrées mises en cache avec ceux spécifiés dans l'en-tête `If-None-Match`. Si une correspondance est trouvée, Edge renvoie un statut 304 Non modifié. 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 le statut 304 Non modifié
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 que Edge 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, celui-ci 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 transité par 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 statut 304 Non modifié, Edge renvoie la valeur de réponse si l'en-tête Last-Modified de la réponse mise en cache indique qu'elle n'a pas changé.

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.