Comment les requêtes sont mises en correspondance à une configuration d’itinéraire

  • Article

Dans Azure Front Door, un itinéraire définit la façon dont le trafic est géré quand la requête entrante arrive à la périphérie Azure Front Door. Par le biais des paramètres d’itinéraire, une association est définie entre un domaine et un groupe d’origine. En utilisant des fonctionnalités avancées telles que Modèle à suivre et Ensemble de règles, vous pouvez avoir un contrôle granulaire du trafic vers vos ressources back-end.

Notes

Quand vous utilisez les ensembles de règles Front Door, vous pouvez configurer une règle pour remplacer le groupe d’origine pour une requête. Le groupe d’origine défini par l’ensemble de règles remplace le processus de routage décrit dans cet article.

Important

Azure Front Door (classique) va être mis hors service le 31 mars 2027. Pour éviter toute interruption de service, il est important de migrer vos profils Azure Front Door (classique) vers le niveau Azure Front Door Standard ou Premium au plus en mars 2027. Pour plus d’informations, consultez Mise hors service d'Azure Front Door (classique).

Quand une requête arrive à la périphérie Azure Front Door (classique), l’une des premières actions effectuées par Front Door est de déterminer comment acheminer la requête correspondante vers une ressource back-end, puis d’effectuer une action définie dans la configuration d’itinéraire. Le document suivant explique comment Front Door détermine la configuration d’itinéraire à utiliser pendant le traitement d’une requête.

Structure d’une configuration d’itinéraire de porte d’entrée

Une règle d’itinéraire Front Door est constituée de deux parties principales : le « côté gauche » et le « côté droit ». Front Door fait correspondre la requête entrante au côté gauche de l’itinéraire, tandis que le côté droit définit le mode de traitement de la requête.

Mise en correspondance de la demande entrante (côté gauche)

Les propriétés suivantes déterminent si la demande entrante correspond à la règle de routage (ou côté gauche) :

  • Protocoles HTTP – HTTP ou HTTPS
  • Domaine – Par exemple : www.foo.com, *.bar.com
  • Chemins d’accès – Par exemple : /*, /users/*, /file.gif

Ces propriétés sont développées en interne de telle sorte que chaque combinaison Protocole/Domaine/Chemin d’accès constitue un ensemble de correspondances potentiel.

Décision de routage (côté droit)

Le choix de la façon de traiter la requête dépend de l’activation de la mise en cache pour l’itinéraire. Si une réponse mise en cache n’est pas disponible, la requête est transférée à l’origine appropriée.

Mise en correspondance avec un itinéraire

Cette section se concentre sur la façon dont Front Door établit une correspondance avec une règle d’acheminement. L’idée de base est que Front Door établit toujours une correspondance avec la requête la plus spécifique en tenant compte uniquement du « côté gauche ». Front Door établit tout d’abord des correspondances en fonction du protocole, puis du domaine et enfin du chemin d’accès.

Mise en correspondance avec des hôtes frontend

Azure Front Door utilise la logique suivante pour faire correspondre les hôtes front-end :

  1. Déterminer s’il existe des itinéraires avec une correspondance exacte sur l’hôte front-end.
  2. S’il n’y a pas de correspondance exacte des hôtes front-end, la requête est rejetée et une erreur 400 Requête incorrecte est envoyée.

Le tableau ci-dessous présente trois règles d’acheminement différentes avec un hôte front-end et des chemins d’accès :

Règle de routage Hôtes frontend Path
Un foo.contoso.com /*
B foo.contoso.com /users/*
C www.fabrikam.com, foo.adventure-works.com /*, /images/*

Le tableau ci-dessous présente les résultats correspondants pour les règles d’acheminement ci-dessus :

Hôte frontend entrant Règle(s) de routage correspondante(s)
foo.contoso.com A, B
www.fabrikam.com C
images.fabrikam.com Erreur 400 : Demande incorrecte
foo.adventure-works.com C
contoso.com Erreur 400 : Demande incorrecte
foo.adventure-works.com Erreur 400 : Demande incorrecte
www.northwindtraders.com Erreur 400 : Demande incorrecte

Mise en correspondance avec un chemin

Après que Front Door a déterminé l’hôte front-end spécifique et filtré les règles d’acheminement possibles, Front Door sélectionne les règles d’acheminement en fonction du chemin de la requête. Une logique similaire aux hôtes front-end est utilisée pour faire correspondre le chemin de la requête :

  1. Déterminer s’il existe des règles d’acheminement avec une correspondance exacte avec le chemin de la requête.
  2. S’il n’existe pas de chemin d’accès correspondant exact, Front Door recherche une règle d’acheminement avec un chemin d’accès générique correspondant.
  3. Si aucune règle d’acheminement n’est trouvée avec un chemin d’accès correspondant, la requête est rejetée et une erreur 400 Requête incorrecte est envoyée.

Remarque

Le caractère * générique n’est valide que pour les chemins d’accès qui n’ont pas d’autres caractères après celui-ci. En outre, le caractère * générique doit être précédé d’une barre oblique /. Les chemins sans caractère générique sont considérés comme des correspondances parfaites. Un chemin qui se termine par une barre oblique / est également un chemin de correspondance exacte. Assurez-vous que vos chemins suivent ces règles pour éviter toute erreur.

Remarque

  • Les chemins sans caractère générique sont considérés comme des correspondances parfaites. Si un chemin se termine par /, il est considéré comme une correspondance exacte.
  • Les chemins d’accès du paramètre Modèles à mettre en correspondance ne respectent pas la casse, ce qui signifie que les chemins d’accès ayant une casse différente sont traités comme des doublons. Par exemple, vous avez le même hôte qui utilise le même protocole avec les chemins d’accès /FOO et /foo. Ces chemins d’accès sont considérés comme des doublons, ce qui n’est pas autorisé dans le paramètre Modèles à mettre en correspondance.

Le tableau ci-dessous répertorie des combinaisons de règle d’acheminement, d’hôte frontal et de chemin d’accès :

Règle de routage Hôte frontend Path
Un www.contoso.com /
B www.contoso.com /*
C www.contoso.com /ab
D www.contoso.com /abc
E www.contoso.com /abc/
F www.contoso.com /abc/*
G www.contoso.com /abc/def
H www.contoso.com /path/

Le tableau ci-dessous indique la règle d’acheminement à laquelle la requête entrante est mise en correspondance quand elle arrive à la périphérie Front Door :

Demandes entrantes Itinéraire correspondant
www.contoso.com/ A
www.contoso.com/a B
www.contoso.com/ab C
www.contoso.com/abc D
www.contoso.com/abzzz B
www.contoso.com/abc/ E
www.contoso.com/abc/d F
www.contoso.com/abc/def G
www.contoso.com/abc/defzzz F
www.contoso.com/abc/def/ghi F
www.contoso.com/path B
www.contoso.com/path/ H
www.contoso.com/path/zzz B

Avertissement

En l’absence de règle de routage pour un hôte frontend parfaitement concordant avec un chemin d’itinéraire fourre-tout (/*), il n’existe pas de correspondance avec une règle de routage.

Exemple de configuration :

Routage Host Path
Un profile.contoso.com /api/*

Tableau des correspondances :

Requête entrante Itinéraire correspondant
profile.domain.com/other Aucun. Erreur 400 : Demande incorrecte

Décision de routage

Une fois que Front Door a déterminé une seule règle d’acheminement, il doit ensuite choisir comment traiter la requête. Si Azure Front Door a une réponse en cache pour la règle d’acheminement correspondante, la requête est renvoyée au client.

Enfin, Azure Front Door détermine si vous avez ou non un ensemble de règles configuré pour la règle d’acheminement en correspondance. Si aucun ensemble de règles n’est défini, la requête est transférée telle quelle au groupe d’origine. Sinon, les ensembles de règles sont traités dans l’ordre où ils sont configurés. Les ensembles de règles peuvent remplacer un itinéraire en forçant le trafic vers un groupe d’origine spécifique.

Si Front Door (classique) n’a pas de réponse en cache pour la règle d’acheminement correspondante, il détermine si la réécriture d’URL est configurée pour la règle d’acheminement correspondante. En l’absence de chemin de transfert personnalisé, la requête est transférée en l’état au serveur back-end approprié dans le pool back-end configuré. Si un chemin de transfert personnalisé a été défini, le chemin de la requête est mis à jour tel qu’il est défini dans le chemin de transfert personnalisé, puis transféré au serveur back-end.

Étapes suivantes