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

Politique de mise en cache par défaut

Les configurations de cache s'appliquent uniquement aux requêtes acheminées vers le composant de cache ESA. ESA suit les étapes suivantes pour déterminer si une requête doit être mise en cache :

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

2. Vérifiez si la requête respecte les conditions spécifiées dans une règle de cache. Si c'est le cas, la règle de cache s'applique à la requête, plutôt que les paramètres de cache globaux. Pour plus d'informations, consultez la section Règles de cache pour les réponses réussies et les redirections.

3. Vérifiez si l'extension du fichier figure dans la liste des extensions des fichiers mis en cache par défaut. Si tel est le cas, les paramètres de cache globaux s'appliquent à la requête.

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

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

Le TTL du cache de périphérie 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 mise en cache, ESA applique la politique de cache du serveur d'origine. En l'absence de ces en-têtes dans la réponse, ESA met en cache les ressources selon sa politique par défaut.

  Détails de la politique de mise en 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. Si l'en-tête Cache-Control contient l'une des directives ci-dessous, la ressource n'est pas mise en cache :

     • no-cache

     • no-store

     • max-age=0

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

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

  Si la réponse d'origine ne contient pas l'en-tête Cache-Control, la politique de mise en cache par défaut d'ESA s'applique. La priorité des en-têtes (de la plus élevée à la plus faible) est la suivante : Expires > Last-Modified > ETag.

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

  2. Si la réponse d'origine ne contient pas l'en-tête Expires mais inclut l'en-tête Last-Modified, le TTL est calculé selon les règles suivantes :

     • TTL = (Heure actuelle - Valeur de Last-Modifie d) × 0,1. Si le résultat se situe entre 10 et 3 600 secondes, cette valeur est appliquée. En dessous de 10 secondes, le TTL est fixé à 10 secondes. Au-delà de 3 600 secondes, il est plafonné à 3 600 secondes.

  3. Si la réponse d'origine ne contient que l'en-tête ETag, le TTL est de 10 secondes.

  4. Si la réponse d'origine ne contient aucun des en-têtes Cache-Control, Expires, ETag ou Last-Modified, la ressource n'est pas mise en cache.

• Honor Origin TTL or Do Not Cache : Si la réponse du serveur d'origine contient l'en-tête Cache-Control définissant une politique de cache, ESA respecte cette politique. En l'absence de cet en-tête Cache-Control, ESA ne met pas les ressources en cache.

  Détails de la politique de mise en cache

  

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

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

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

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

• Do Not Cache : Aucune ressource récupérée depuis le serveur d'origine n'est mise en cache sur les nœuds POP d'ESA.

• Use Custom TTL : ESA ignore les en-têtes Cache-Control, Expires, Last-Modified et ETag présents dans la réponse d'origine et applique le TTL configuré sur ESA.

Comportement du cache vis-à-vis de Set-Cookie

Pour les codes d'état standards tels que 200, 203 et 206, la décision de mise en cache d'ESA ne vérifie pas l'en-tête de réponse Set-Cookie. Elle s'appuie uniquement sur les en-têtes Cache-Control, Expires, Last-Modified et ETag pour déterminer si la réponse doit être mise en cache. Si le serveur d'origine renvoie un code 200 accompagné d'un en-tête Set-Cookie, et que Cache-Control autorise la mise en cache (par exemple, max-age=600), ESA met la réponse en cache, y compris l'en-tête Set-Cookie. Dans ce cas, les requêtes provenant d'utilisateurs différents peuvent atteindre la même copie mise en cache et recevoir la même valeur Set-Cookie, ce qui peut entraîner une fuite de session entre comptes.

Ce comportement diffère de celui appliqué aux codes d'erreur : pour les codes 204, 305, 404, 405, 414, 424, 429, 500, 501, 502, 503 et 504, si le serveur d'origine renvoie un en-tête de réponse set-cookie, ESA ne met pas la réponse en cache. En revanche, les réponses normales telles que 200 ne sont pas exclues du cache simplement parce qu'elles contiennent un en-tête Set-Cookie.

Pour les contenus dynamiques tels que les sessions de connexion, les pages du centre utilisateur et les commandes, nous vous recommandons de configurer Cache-Control: no-cache ou no-store sur le serveur d'origine afin d'empêcher ESA de mettre en cache les réponses contenant Set-Cookie. Pour les étapes de dépannage, consultez @xref node="5045753" Éligibilité au cache @/xref .

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

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

  

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

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

     1. Si un TTL est configuré, la réponse est mise en cache selon les paramètres de la console. En cas de règles multiples, celle ayant le numéro d'ordre le plus petit s'applique.

     2. Si aucun TTL n'est configuré, la réponse est mise en cache en fonction des en-têtes de réponse Pragma, Cache-Control ou Expires provenant du serveur d'origine.

  3. Si le serveur d'origine ne renvoie aucun des en-têtes de réponse Pragma, Cache-Control ou Expires, la réponse est mise en cache par défaut pendant 1 seconde.

• Pour les codes d'état 302, 307 et 403, les règles de mise en cache sont les suivantes :

  

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

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

     1. Si un TTL est configuré, la réponse est mise en cache selon les paramètres de la console. En cas de règles multiples, celle ayant le numéro d'ordre le plus petit s'applique.

     2. Si aucun TTL n'est configuré, la réponse est mise en cache en fonction des en-têtes de réponse Pragma, Cache-Control ou Expires provenant du serveur d'origine.

  3. Si le serveur d'origine ne renvoie aucun des en-têtes de réponse Pragma, Cache-Control ou Expires, la réponse n'est pas mise en cache.

• Pour les autres codes d'erreur, tels que 400, les règles de mise en cache sont les suivantes :

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

  2. Si le serveur d'origine ne renvoie pas d'en-tête de réponse set-cookie, le système vérifie si un TTL est configuré pour ce code d'état dans la console. En cas de règles multiples, celle ayant le numéro d'ordre le plus petit s'applique.

  3. Dans tous les autres cas, la réponse n'est pas mise en cache.

• Pour les requêtes utilisant la récupération d'origine par plage (range origin fetch), si un nœud POP reçoit une réponse avec un code d'état différent de 206 de la part du serveur d'origine, il supprime les fragments de fichier mis en cache. Un délai d'expiration lors de la récupération d'origine n'entraîne pas la suppression des fichiers en cache.

  Lors de l'utilisation de la récupération d'origine par plage, le serveur d'origine divise un fichier volumineux en plusieurs fragments plus petits et les envoie au nœud POP. Par exemple, un fichier est divisé en 10 fragments et le POP en a mis 5 en cache. Lorsque le POP demande le 6e fragment et que le serveur d'origine renvoie un code d'état 5xx, le POP supprime les 5 fragments précédemment mis en cache.

Informations sur la réponse du cache

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

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

  • Sa valeur est un horodatage UNIX. Par exemple : 1745053111 indique 16:58:31 le 19 avril 2025.

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

  • La date est mise à jour lorsque le POP ESA initie une requête vers l'origine contenant l'en-tête If-Modified-Since ou If-None-Match pour revalider la ressource et que le serveur d'origine renvoie le code d'état HTTP 304.

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

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

  • HIT : la ressource se trouve dans le cache du POP ESA.

  • MISS : la ressource ne se trouve pas dans le cache du POP ESA. Le POP récupère la ressource depuis le serveur d'origine, puis la renvoie au client.

  • NONE/UNKNOWN : la ressource n'est pas éligible à la mise en cache pour les raisons suivantes :

    • Une fonction Edge génère une réponse mais n'envoie aucune 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 Edge initie une sous-requête (fetch), l'état du cache est enregistré pour la sous-requête, tandis que l'état du cache de la requête principale est enregistré comme none/unknown. Cela s'explique par le fait que le module de fonction Edge s'exécute avant le module de cache, empêchant la requête principale de passer par le cache.

    • Une requête client correspond à une règle WAF personnalisée et est bloquée par le WAF. Étant donné que le 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 à des Redirections de requête ou à des Règles HTTPS. Le POP envoie alors une réponse de redirection vers une autre URL. Comme ces règles s'exécutent avant le module de cache, l'état du cache est enregistré comme none/unknown.

  • EXPIRED : la ressource se trouve dans le cache du POP ESA mais a expiré. Le POP récupère la ressource depuis le serveur d'origine, puis la renvoie au client. Le code d'état renvoyé par le serveur d'origine est 200 ou 206.

  • STALE :

    La ressource est servie depuis le cache du POP ESA mais a expiré. Cela 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 et sert le cache 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 cache expiré au client lorsque ESA ne peut pas se connecter au serveur d'origine pour récupérer la ressource mise à jour.

    • La fonctionnalité Configurer la diffusion de contenu périmé est activée. Cette fonctionnalité permet au POP ESA de servir le cache expiré au client lorsque la réponse du serveur d'origine expire ou lorsque le serveur d'origine est inaccessible.

  • BYPASS

    La requête vers la ressource contourne le cache ESA. Cela se produit dans les cas suivants :

    • Le paramètre de cache n'est pas défini sur Honor Origin TTL et ESA définit un TTL de cache personnalisé à 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ée par le serveur d'origine est no-store.

  • REVALIDATED

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

  • DYNAMIC

    ESA détecte que la ressource est un contenu dynamique et qu'aucune règle de cache définie ne s'applique à cette requête. Dans ce cas, ESA récupère la ressource depuis le serveur d'origine, puis la renvoie au client.

• X-Swift-Cachetime : spécifie le TTL de la ressource sur le POP en secondes. La valeur X-Swift-Cachetime n'est pas identique au TTL défini dans ESA. Elle est calculée à l'aide de la formule suivante : X-Swift-Cachetime = Ali-Swift-Global-Savetime + le TTL défini dans ESA - X-Swift-SaveTime. Les scénarios suivants peuvent se produire :

  • La valeur X-Swift-Cachetime est égale au TTL défini dans ESA, par exemple 3 600 secondes.

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

    • Une latence élevée se produit lorsqu'un nœud de niveau 1 récupère du contenu depuis un nœud de niveau 2.

    • Les horloges des nœuds de niveau 1 et de niveau 2 ne sont pas synchronisées.

  • La valeur X-Swift-Cachetime est négative. Cela peut se produire si vous modifiez le paramètre TTL dans ESA après la mise en cache d'une ressource. Cela arrive lorsqu'une requête client arrive après l'expiration du cache du nœud de niveau 1, mais alors que le cache du nœud de niveau 2 est toujours valide. Par exemple, le TTL était initialement défini sur 3 600 secondes dans ESA et a ensuite été modifié à 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, vous pouvez actualiser le cache.

• X-Swift-Cachetime :

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

• X-Swift-SaveTime :

  • L'heure à laquelle la ressource est entrée pour la première fois dans le POP actuel (POP de niveau 1) qui reçoit la requête du client.

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

Politique Ne pas mettre en cache

Le POP ESA ne met pas les fichiers en cache et transmet toutes les requêtes de fichiers dans les conditions suivantes :

• Le paramètre Edge Cache TTL sur la page Paramètres de ESA 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 sur la page Paramètres de ESA est défini sur Do Not Cache.

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

Revalidation du cache

Après l'expiration d'un fichier mis en cache sur le POP ESA, le POP ESA 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 retélécharger. Cela réduit le trafic vers l'origine et améliore la vitesse 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 sur la page Paramètres de ESA est défini sur Honor Origin TTL or Use Default Cache Rule et la réponse d'origine remplit les conditions suivantes :

    • Cache-Control: no-cache

    • Cache-Control: max-age=0

• Configuration de politique régulière : le serveur d'origine répond à la politique liée à la validation du cache et le POP ESA exécute la politique réelle.

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

    • must-revalidate

    • proxy-revalidate

    • stale-while-revalidate=seconds

    • stale-if-error=seconds

• Politique de validation du cache

  Politiques de validation du cache :

  • must-revalidate

    • Description : une fois expiré, tout cache (proxy ou navigateur) doit revalider la ressource auprès du serveur d'origine avant de la servir. Le cache ne peut pas servir 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 l'expiration, le cache sert le contenu périmé pendant la durée spécifiée tout en revalidant de manière asynchrone avec l'origine en arrière-plan. Utilisez cette option lorsque la réduction de la latence l'emporte sur la diffusion de contenu brièvement périmé.

    • 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 première publication. Une fois expirée, la ressource peut encore être fournie aux utilisateurs pendant les 60 secondes suivantes. Parallèlement, le POP tente d'obtenir les mises à jour depuis le serveur d'origine.

  • stale-if-error=seconds

    • Description : lorsque l'origine est inaccessible (panne du serveur, erreur réseau), le POP sert le contenu mis en cache expiré pendant la durée spécifiée. Cela améliore la tolérance aux pannes et maintient la disponibilité pendant les 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 première publication. Si la revalidation après les 86 400 secondes échoue, la dernière ressource mise en cache avec succès peut encore être fournie pendant les 604 800 secondes suivantes (une semaine).