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.

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.

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.

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.

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.

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.

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.
  1. 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.
  2. Si une correspondance est trouvée, l'entrée du cache est renvoyée.
  3. 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.
  1. 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.
  2. 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.