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

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

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d' Apigee Edge.

Cet article explique comment Apigee gère les en-têtes de mise en cache HTTP/1.1 lorsque vous utilisez la règle ResponseCache. Apigee 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, Apigee 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, Apigee 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, Apigee 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, Apigee 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. Apigee 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	Apigee envoie des réponses compressées ou non compressées en fonction des en-têtes entrants.

Cache-Control

Apigee 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, et ceux créés à l'aide d'appels d'API TargetServer.

Limites de compatibilité de Cache-Control

Apigee 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 n'accepte pas les en-têtes Cache-Control qui arrivent avec des requêtes client entrantes.
Apigee est compatible avec la notion de cache public uniquement. (D'après la spécification HTTP, Cache-Control peut être public (partagé) ou privé (utilisateur unique).
Apigee 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 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 traite l'instruction
`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 dès leur expiration.
`no-cache`	Apigee 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 dès leur expiration.
`public`	Apigee 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, Apigee 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 à Apigee avec un ETag, Apigee 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 Apigee 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 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 Apigee 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 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, Apigee renvoie l'état "304 Not Modified". Si aucune correspondance n'est trouvée, Apigee 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.	Apigee 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'Apigee la renvoie au client.
Apigee reçoit un ETag d'un serveur d'origine.	L'ETag est renvoyé inchangé au client.

If-Modified-Since

Si Apigee 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 sont prises en compte. Si le serveur d'origine renvoie une nouvelle entité, Apigee remplace l'entrée de cache existante par la nouvelle valeur. Si le serveur renvoie un état "304 Not modified", Apigee 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.