Edge Security Acceleration:Règles de cache par défaut

Politique de cache par défaut

Les configurations de cache concernent exclusivement les requêtes acheminées vers le composant de cache ESA. ESA détermine si une requête entre dans le cache en suivant les étapes ci-dessous :

1. Vérifiez si la requête est de type GET ou HEAD.

2. Contrôlez si la requête remplit les conditions spécifiées dans une règle de cache. Si tel est le cas, cette règle s'applique à la requête à la place des paramètres de cache globaux. Pour plus d'informations, consultez Règles de cache pour les réponses réussies et les redirections.

3. Vérifiez si l'extension du fichier figure parmi les extensions des fichiers mis en cache par défaut. Dans l'affirmative, les paramètres de cache globaux s'appliquent à la requête.

Règles de cache pour les réponses réussies et les redirections

Codes d'état applicables : 200, 203, 206, 300, 301 et 410.

La TTL du cache périphérique propose quatre options :

• Honor Origin TTL or Use Default Cache Rule : si la réponse renvoyée par le serveur d'origine contient les en-têtes Cache-Control, Expires, Last-Modified et ETag permettant de définir une politique de cache, ESA applique celle du serveur d'origine. En l'absence de tout en-tête Cache-Control, Expires, Last-Modified ou ETag dans la réponse, ESA met les ressources en cache selon sa propre politique par défaut.

  Détails de la politique de cache

  

  Présence de l'en-tête Cache-Control dans la réponse

  L'en-tête Cache-Control de la réponse d'origine spécifie l'une des politiques suivantes :

  1. La ressource n'est pas mise en cache si l'en-tête Cache-Control contient l'une des directives suivantes :

     • no-cache

     • no-store

     • max-age=0

  2. Lorsque l'en-tête Cache-Control inclut la directive max-age ou s-maxage avec une valeur supérieure à 0 (par exemple 3600), la TTL indiquée par cette directive s'applique. Si les deux directives max-age et s-maxage coexistent, la valeur de s-maxage prévaut.

  Absence de l'en-tête Cache-Control dans la réponse

  Si la réponse d'origine ne comporte pas l'en-tête Cache-Control, la politique de cache par défaut d'ESA prend le relais. Les en-têtes sont évalués selon l'ordre de priorité suivant (du plus élevé au plus faible) : Expires > Last-Modified > ETag.

  1. Quand la réponse d'origine contient l'en-tête Expires (par exemple Expires:Tue, 25 Nov 2031 17:25:43 GMT), ESA utilise la TTL définie dans cet en-tête.

  2. En l'absence de l'en-tête Expires mais en présence de l'en-tête Last-Modified, la TTL est calculée selon la règle suivante :

     • TTL = (heure actuelle - valeur de Last-Modifie d) × 0,1. Si le résultat se situe entre 10 et 3 600 secondes, cette valeur exacte est conservée. Un résultat inférieur à 10 secondes fixe la TTL à 10 secondes, tandis qu'un résultat supérieur à 3 600 secondes limite la TTL à 3 600 secondes.

  3. Si la réponse d'origine ne fournit que l'en-tête ETag, la TTL est fixée à 10 secondes.

  4. Aucune mise en cache n'a lieu lorsque la réponse d'origine ne contient ni l'en-tête Cache-Control, ni Expires, ni ETag, ni Last-Modified.

• Honor Origin TTL or Do Not Cache : si la réponse du serveur d'origine inclut l'en-tête Cache-Control définissant une politique de cache, ESA respecte celle-ci. Sans cet en-tête Cache-Control, ESA ne met aucune ressource en cache.

  Détails de la politique de cache

  

  Détermination de la politique de cache du serveur d'origine

  Vérifiez la présence de l'en-tête Cache-Control dans la réponse d'origine. S'il manque, les ressources ne sont pas mises en cache. S'il est présent, l'une des politiques suivantes s'applique :

  1. Les ressources ne sont pas mises en cache si l'en-tête Cache-Control contient la directive no-cache, no-store ou max-age=0.

  2. Lorsque l'en-tête Cache-Control inclut la directive max-age ou s-maxage avec une valeur supérieure à 0 (comme 3600), la TTL précisée par cette directive est retenue. En cas de présence simultanée des directives max-age et s-maxage, la valeur de s-maxage prime.

• Do Not Cache : aucune ressource récupérée depuis le serveur d'origine n'est stockée sur les POP ESA.

• Use Custom TTL : ESA ignore les en-têtes Cache-Control, Expires, Last-Modified et ETag de la politique de cache figurant dans la réponse d'origine, puis applique la TTL configurée dans ESA.

Règles de cache pour les réponses avec des codes d'état d'erreur

• Pour les codes d'état 204, 305, 404, 405, 414, 424, 429, 500, 501, 502, 503 et 504, les règles de cache sont les suivantes :

  

  1. La réponse n'est pas mise en cache si le serveur d'origine renvoie un en-tête de réponse set-cookie.

  2. Si le serveur d'origine ne renvoie aucun en-tête de réponse set-cookie, le système vérifie si une TTL est configurée pour ce code d'état dans la console :

     1. Lorsqu'une TTL est définie, la réponse est mise en cache conformément aux paramètres de la console. Si plusieurs règles existent, celle portant le plus petit numéro d'ordre s'applique.

     2. Sans TTL configurée, la mise en cache de la réponse repose sur les en-têtes de réponse Pragma, Cache-Control ou Expires fournis par le serveur d'origine.

  3. En l'absence des en-têtes de réponse Pragma, Cache-Control et Expires de la part du serveur d'origine, la réponse est mise en cache pendant 1 seconde par défaut.

• Concernant les codes d'état 302, 307 et 403, les règles de cache fonctionnent ainsi :

  

  1. Un en-tête de réponse set-cookie renvoyé par le serveur d'origine empêche la mise en cache de la réponse.

  2. Si le serveur d'origine ne renvoie pas d'en-tête de réponse set-cookie, le système recherche une éventuelle TTL configurée pour ce code d'état dans la console :

     1. Une TTL configurée entraîne la mise en cache de la réponse selon les paramètres de la console. En présence de plusieurs règles, celle dotée du plus petit numéro d'ordre prend effet.

     2. Faute de TTL configurée, la mise en cache de la réponse dépend des en-têtes de réponse Pragma, Cache-Control ou Expires émis par le serveur d'origine.

  3. La réponse n'est pas mise en cache si le serveur d'origine ne renvoie ni l'en-tête Pragma, ni Cache-Control, ni Expires.

• Pour les autres codes d'état d'erreur, comme 400, les règles de cache s'établissent comme suit :

  1. La réponse n'est pas mise en cache dès lors que le serveur d'origine renvoie un en-tête de réponse set-cookie.

  2. Sans en-tête de réponse set-cookie de la part du serveur d'origine, le système vérifie si une TTL est définie pour ce code d'état dans la console. Si plusieurs règles coexistent, celle ayant le plus petit numéro d'ordre s'applique.

  3. Dans tous les autres cas, aucune mise en cache de la réponse n'intervient.

• Pour les requêtes utilisant une extraction d'origine par plage, si un POP reçoit du serveur d'origine une réponse dont le code d'état diffère de 206, il supprime les fragments de fichiers mis en cache. Un délai d'expiration de l'extraction d'origine n'entraîne pas la suppression des fichiers en cache.

  Lors de l'utilisation de l'extraction d'origine par plage, le serveur d'origine divise un fichier volumineux en plusieurs fragments plus petits et les transmet au POP. Par exemple, si un fichier est découpé en 10 fragments et que le POP en a déjà mis 5 en cache, la réception d'un code d'état 5xx lors de la demande du 6e fragment conduit le POP à supprimer les 5 fragments stockés.

Informations de réponse du cache

Les POP ESA renvoient des en-têtes de réponse liés au cache contenant les informations suivantes :

• Ali-Swift-Global-Savetime : heure à laquelle la ressource est entrée pour la première fois dans le POP ESA (déterminée par l'architecture de cache du site web, qui peut être un POP L2 ou un POP d'un autre niveau de cache).

  • Sa valeur correspond à un horodatage UNIX. Par exemple, 1745053111 représente 16:58:31 on April 19, 2025.

• Date : date à laquelle le serveur d'origine a renvoyé la ressource au POP ESA.

  • Cette date est actualisée lorsque le POP ESA initie une requête d'origine contenant l'en-tête If-Modified-Since ou If-None-Match pour revalider la ressource, et que le serveur d'origine répond avec le code d'état HTTP 304.

  • L'heure est exprimée au format GMT. Exemple : Sat, 19 Apr 2025 08:58:31 GMT.

• X-Site-Cache-Status : état du cache de la ressource demandée sur le POP ESA. La liste suivante décrit les différents états de la ressource :

  • HIT : la ressource est trouvée dans le cache du POP ESA.

  • MISS : la ressource est introuvable dans le cache du POP ESA. Le POP récupère alors la ressource auprès du serveur d'origine avant de la transmettre au client.

  • NONE/UNKNOWN : la ressource ne peut pas être mise en cache pour les raisons suivantes :

    • Une fonction périphérique génère une réponse sans envoyer de sous-requête. Dans ce cas, la réponse ne provient pas du cache et l'état du cache est enregistré comme none/unknown.

    • Lorsque la requête principale d'une fonction périphérique déclenche une sous-requête (fetch), l'état du cache est consigné pour cette sous-requête, tandis que celui de la requête principale est enregistré comme none/unknown. Ce comportement s'explique par le fait que le module de fonction périphérique s'exécute avant le module de cache, empêchant ainsi la requête principale de traverser le cache.

    • Une requête client correspond à une règle WAF personnalisée et se trouve bloquée par WAF. Comme WAF s'exécute avant le module de cache, la requête ne passe pas par le cache et l'état du cache est enregistré comme none/unknown.

    • Une requête client correspond à une règle de Redirections de requêtes ou à une règle HTTPS. Le POP envoie ensuite une réponse de redirection vers une autre URL. Ces règles s'exécutant avant le module de cache, l'état du cache est enregistré comme none/unknown.

  • EXPIRED : la ressource est présente dans le cache du POP ESA, mais elle a expiré. Le POP récupère donc la ressource auprès du serveur d'origine, puis la renvoie au client. Le code d'état retourné par le serveur d'origine est 200 ou 206.

  • STALE :

    La ressource est servie depuis le cache du POP ESA, bien qu'elle ait expiré. Cette situation se produit dans les cas suivants :

    • Le paramètre de cache est défini sur Honor Origin TTL et la réponse d'origine contient Cache-Control:stale-while-revalidate=<seconds>. Pendant la durée spécifiée, ESA initie une requête vers le serveur d'origine pour revalider la ressource, tout en servant le contenu expiré au client.

    • Le paramètre de cache est défini sur Honor Origin TTL et la réponse d'origine contient Cache-Control:stale-if-error=<seconds>. Pendant la durée spécifiée, ESA sert le contenu expiré au client lorsqu'ESA ne parvient pas à se connecter au serveur d'origine pour récupérer la ressource mise à jour.

    • La fonctionnalité Configurer la diffusion de contenu obsolète est activée. Elle permet au POP ESA de servir le contenu expiré au client lorsque la réponse d'origine expire ou que le serveur d'origine est injoignable.

  • BYPASS

    La requête visant la ressource contourne le cache ESA. Cela se produit dans les situations suivantes :

    • Le paramètre de cache n'est pas défini sur Honor Origin TTL et ESA fixe une TTL de cache personnalisée à 0 seconde.

    • Le paramètre de cache est défini sur Honor Origin TTL, mais la valeur de l'en-tête Cache-Control renvoyé par le serveur d'origine est no-store.

  • REVALIDATED

    La ressource est servie par le cache ESA, mais elle a expiré. ESA initie alors une requête d'origine contenant l'en-tête If-Modified-Since ou lf-None-Match vers le serveur d'origine afin de revalider la ressource. Le serveur d'origine répond avec le code d'état HTTP 304.

  • DYNAMIC

    ESA détecte que la ressource constitue du contenu dynamique et qu'aucune règle de cache définie ne s'applique à ce type de requête. Dans ce cas, ESA récupère la ressource auprès du serveur d'origine, puis la transmet au client.

• X-Swift-Cachetime : indique la TTL de la ressource sur le POP, en secondes. La valeur de X-Swift-Cachetime diffère de la TTL définie dans ESA. Elle est calculée selon la formule suivante : X-Swift-Cachetime = Ali-Swift-Global-Savetime + la TTL définie dans ESA - X-Swift-SaveTime. Plusieurs scénarios peuvent se présenter :

  • La valeur de X-Swift-Cachetime est égale à la TTL définie dans ESA, par exemple 3 600 secondes.

  • La valeur de X-Swift-Cachetime est légèrement inférieure à la TTL définie dans ESA. Par exemple, si la TTL configurée dans ESA est de 300 secondes, la valeur de X-Swift-Cachetime peut être de 295 secondes. Cet écart s'explique par les raisons suivantes :

    • Une latence élevée survient lorsqu'un nœud L1 récupère du contenu auprès d'un nœud L2.

    • Les horloges des nœuds L1 et L2 ne sont pas synchronisées.

  • La valeur de X-Swift-Cachetime est négative. Ce cas se produit si vous modifiez le paramètre de TTL dans ESA après la mise en cache d'une ressource. Il survient lorsqu'une requête client arrive après l'expiration du cache du nœud L1, mais pendant que le cache du nœud L2 reste valide. Par exemple, la TTL était initialement fixée à 3 600 secondes dans ESA, puis ramenée à 300 secondes. Si un client envoie une requête 600 secondes après la mise en cache de la ressource, la réponse inclut X-Swift-Cachetime:-300. Pour résoudre ce problème, actualisez le cache.

• X-Swift-Cachetime :

  TTL de cache de la ressource sur le POP ESA. Unité : secondes.

• X-Swift-SaveTime :

  • Heure à laquelle la ressource est entrée pour la première fois dans le POP actuel (POP L1) recevant la requête client.

  • L'heure est exprimée au format GMT. Exemple : Sat, 19 Apr 2025 08:58:31 GMT.

Politique Do Not Cache

Le POP ESA ne met aucun fichier en cache et laisse passer toutes les requêtes de fichiers dans les situations suivantes :

• Le paramètre Edge Cache TTL de la page ESA Paramètres est défini sur Honor Origin TTL or Do Not Cache et la réponse d'origine est Cache-Control: no-store.

• Le paramètre Edge Cache TTL de la page ESA Paramètres est défini sur Do Not Cache.

• Le paramètre Edge Cache TTL de la page ESA Paramètres est défini sur Use Custom TTL et la TTL de cache est fixée à 0 seconde.

Revalidation du cache

Après l'expiration d'un fichier mis en cache sur le POP ESA, ce dernier envoie une requête de validation au serveur d'origine lors de la prochaine requête client. Si le fichier n'a pas changé, le serveur d'origine renvoie 304 not-modified, et le POP ESA sert le fichier mis en cache sans le télécharger à nouveau. Cette approche réduit le trafic vers l'origine et accélère les temps de réponse.

• Configuration de politique spéciale : un fichier est mis en cache pendant 0 seconde, et le POP ESA redirige chaque requête vers le serveur d'origine pour validation.

  • Le paramètre Edge Cache TTL de la page ESA Paramètres est défini sur Honor Origin TTL or Use Default Cache Rule, et la réponse d'origine remplit l'une des conditions suivantes :

    • Cache-Control: no-cache

    • Cache-Control: max-age=0

• Configuration de politique standard : le serveur d'origine répond à la politique liée à la validation du cache, et le POP ESA exécute la politique effective.

  • Le paramètre Edge Cache TTL de la page ESA Paramètres est défini sur Honor Origin TTL or Use Default Cache Rule, et la réponse d'origine correspond à l'une des politiques de validation de cache suivantes :

    • must-revalidate

    • proxy-revalidate

    • stale-while-revalidate=seconds

    • stale-if-error=seconds

• Politiques de validation du cache

  Politiques de validation du cache disponibles :

  • must-revalidate

    • Description : une fois la ressource expirée, tout cache (proxy ou navigateur) doit la revalider auprès du serveur d'origine avant de la servir. Le cache ne peut pas fournir de contenu expiré, même si le réseau est indisponible, sauf si la ressource a été validée comme inchangée.

    • Exemple : Cache-Control: max-age=3600, must-revalidate indique qu'une ressource doit être renvoyée au serveur d'origine pour valider sa fraîcheur après son expiration.

  • proxy-revalidate

    • Description : similaire à must-revalidate, mais s'applique uniquement aux caches partagés (CDN, serveurs proxy). Les caches privés, tels que les navigateurs, ne sont pas soumis à cette contrainte.

    • Exemple : Cache-Control: max-age=3600, proxy-revalidate indique qu'une ressource doit être renvoyée au serveur d'origine pour valider sa fraîcheur après son expiration.

  • stale-while-revalidate=seconds

    • Description : après expiration, le cache sert le contenu obsolète pendant la durée spécifiée, tout en effectuant une revalidation asynchrone auprès de l'origine en arrière-plan. Utilisez cette option lorsque la réduction de la latence prime sur la diffusion temporaire d'un contenu obsolète.

    • Exemple : Cache-Control: max-age=3600, stale-while-revalidate=60 indique qu'une ressource est considérée comme fraîche pendant 3 600 secondes (1 heure) après sa publication initiale. Une fois expirée, elle peut encore être fournie aux utilisateurs pendant 60 secondes supplémentaires. Parallèlement, le POP tente d'obtenir les mises à jour auprès du serveur d'origine.

  • stale-if-error=seconds

    • Description : lorsque l'origine est injoignable (panne du serveur, erreur réseau), le POP sert le contenu mis en cache expiré pendant la durée spécifiée. Cette approche améliore la tolérance aux pannes et maintient la disponibilité lors des interruptions de l'origine.

    • Exemple : Cache-Control: max-age=86400, stale-if-error=604800 indique qu'une ressource est considérée comme fraîche pendant 86 400 secondes (24 heures) après sa publication initiale. Si la revalidation échoue au terme de ces 86 400 secondes, la dernière ressource mise en cache avec succès peut encore être fournie pendant 604 800 secondes supplémentaires (une semaine).