En bref. Un remplacement de la configuration de route dans Azure Front Door exige un réglage explicite de mise en cache, faute de quoi celle-ci est désactivée pour la requête correspondante.

Définition : Dans Azure Front Door Standard et Premium, un remplacement de la configuration de route (route configuration override) peut remplacer le groupe d’origines ou la configuration de mise en cache utilisés pour une requête. Lorsque l’action remplace la configuration de route, Azure Front Door exige un réglage explicite de mise en cache ; sans ce réglage, la mise en cache est désactivée pour cette requête.

Points clés

L’action de remplacement de la configuration de route peut modifier le groupe d’origines ou la configuration de mise en cache. Microsoft précise que la mise en cache doit être configurée lorsque la configuration de route est remplacée. La référence des actions d’ensemble de règles de Microsoft décrit ce comportement.
L’option Caching (mise en cache) de la route active la mise en cache du contenu statique dans Azure Front Door. Le guide de configuration des routes de Microsoft décrit cette option parmi les paramètres de route.
La configuration de mise en cache du moteur de règles (Rules Engine) prévaut sur celle de la route. La documentation de Microsoft sur la mise en cache précise aussi qu’un réglage désactivant le cache empêche la mise en cache du contenu des réponses, quelles que soient les directives de réponse de l’origine.
Lorsque la mise en cache est activée, le remplacement peut définir la prise en compte de la chaîne de requête dans la clé de cache, la compression, le comportement du cache et sa durée. La durée maximale de mise en cache documentée pour cette action est de 366 jours.

Quels paramètres le remplacement d’origine modifie-t-il ?

Un groupe d’origines est le groupe vers lequel Azure Front Door transfère le trafic lorsqu’une requête atteint l’origine. Le guide de configuration des routes répertorie le groupe d’origines, le chemin d’origine, le protocole de transfert, la mise en cache et les ensembles de règles parmi les paramètres de route. L’option Caching de la route active la mise en cache du contenu statique.

L’action de règle possède une propriété Override origin group. Lorsqu’elle est définie sur Yes, l’action exige un groupe d’origines et un protocole de transfert. Ces valeurs remplacent les paramètres correspondants de la route du point de terminaison Front Door. La même action possède une propriété Caching distincte, avec deux valeurs acceptées : Enabled, qui force l’activation de la mise en cache pour la requête, et Disabled, qui force sa désactivation.

Cette séparation explique le comportement. Le remplacement du groupe d’origines modifie la destination de la requête, tandis que l’action détermine aussi le choix de mise en cache lorsque la configuration de route est remplacée. La référence des règles précise que l’absence de configuration de mise en cache désactive celle-ci pour la requête.

Pourquoi le remplacement exige-t-il un réglage explicite du cache ?

Azure Front Door évalue la mise en cache en périphérie du réseau (edge). Lorsque la mise en cache est configurée sur une route, le site de périphérie qui reçoit la requête recherche une réponse valide dans le cache. En son absence, la requête est transférée à l’origine. La configuration de mise en cache du moteur de règles prévaut toujours sur celle de la route. Une décision prise au niveau de la règle peut donc remplacer le réglage de la route.

La documentation sur la mise en cache impose d’autres limites aux réponses pouvant être mises en cache. Seules les requêtes GET peuvent être mises en cache. Les réponses dont l’en-tête Cache-Control contient des valeurs telles que private, no-cache ou no-store restent exclues du cache, même lorsque le moteur de règles remplace le comportement de mise en cache. Ces directives figurent dans la réponse de l’origine, tandis que l’action de règle détermine si Front Door applique la mise en cache à la requête correspondante.

Que doit configurer la règle ?

Lorsque l’action définit Caching sur Enabled, Microsoft documente des réglages pour la clé de cache, la compression, le comportement du cache et sa durée. Le comportement du cache peut respecter l’origine, toujours remplacer la durée de vie (TTL) définie par l’origine ou fournir une TTL lorsque l’origine n’en indique aucune. Une durée de mise en cache est obligatoire pour les deux modes de remplacement, et le maximum documenté est de 366 jours.

La référence fournit cet exemple JSON de remplacement de la configuration de route qui inclut customerId dans la clé de cache, active la compression et respecte les politiques de mise en cache de l’origine :

{
  "name": "RouteConfigurationOverride",
  "parameters": {
    "cacheConfiguration": {
      "queryStringCachingBehavior": "IncludeSpecifiedQueryStrings",
      "queryParameters": "customerId",
      "isCompressionEnabled": "Enabled",
      "cacheBehavior": "HonorOrigin",
      "cacheDuration": null
    },
    "originGroupOverride": null,
    "typeName": "DeliveryRuleRouteConfigurationOverrideActionParameters"
  }
}

Le réglage de la chaîne de requête peut ignorer toutes les chaînes de requête, utiliser chaque URL complète, ignorer certains paramètres ou inclure certains paramètres. Si un mode portant sur des paramètres précis est sélectionné, les noms de ces paramètres de requête sont fournis séparément.

Termes associés

Questions fréquentes

Choisir une autre origine désactive-t-il automatiquement la mise en cache ?

L’action de règle documentée regroupe le remplacement du groupe d’origines et les contrôles de mise en cache. Lorsque la configuration de route est remplacée, l’action exige une configuration de mise en cache. L’absence de réglage de mise en cache désactive celle-ci pour la requête.

Un remplacement avec mise en cache activée peut-il mettre toutes les réponses en cache ?

Non. Azure Front Door met uniquement en cache les requêtes GET et respecte les directives de réponse private, no-cache et no-store. Une réponse doit donc rester admissible à la mise en cache après l’application du réglage de la règle.

Quel comportement de cache une règle doit-elle utiliser ?

HonorOrigin suit la directive de réponse de l’origine. OverrideAlways utilise la durée définie dans l’action lorsque la réponse peut être mise en cache, tandis que OverrideIfOriginMissing fournit cette durée lorsque l’origine n’indique aucune TTL de mise en cache.

Sources

Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO

Pourquoi un remplacement d’origine dans Azure Front Door peut-il désactiver la mise en cache ?