Réécrire URL
Azure Front Door prend en charge la réécriture d’URL, ce qui vous permet de modifier le chemin d’accès de la requête acheminé vers votre origine. Cette fonctionnalité puissante vous permet de définir des conditions qui déterminent quand l’URL ou les en-têtes spécifiés doivent être réécrits. Ces conditions sont basées sur les informations présentes dans la requête et la réponse.
En utilisant la réécriture d’URL, vous avez la possibilité de rediriger vos utilisateurs finaux vers différentes origines en fonction de facteurs tels que leur type d’appareil ou le type de fichier qu’ils demandent. L’action de réécriture d’URL peut être facilement configurée dans l’ensemble de règles, ce qui vous offre un contrôle précis sur votre comportement de routage.
Modèle source
Le modèle source représente le chemin d’URL dans la requête initiale que vous souhaitez remplacer. Actuellement, le modèle source utilise une approche de correspondance basée sur des préfixes. Pour faire correspondre tous les chemins d’URL, vous pouvez spécifier une barre oblique (/) comme valeur du modèle source.
Dans le contexte d’une action de réécriture d’URL, seul le chemin d’accès après les modèles de correspondance dans la configuration de l’itinéraire est pris en compte pour le modèle source. Par exemple, l’ensemble de règles considère uniquement /source-pattern comme le modèle source à réécrire si vous avez un format d’URL entrant contoso.com/pattern-to-match/source-pattern. Une fois la réécriture d’URL appliquée, le format d’URL sortant sera contoso.com/pattern-to-match/destination.
Dans les cas où vous devez supprimer le segment /pattern-to-match de l’URL, vous pouvez définir le chemin d’origine pour le groupe d’origines dans la configuration de l’itinéraire pour /.
Destination
Le chemin de destination représente le chemin d’accès qui remplace le modèle source. Par exemple, si le chemin d’URL de la requête est contoso.com/foo/1.jpg, et que le modèle source est /foo/, spécifier la destination comme /bar/ implique que le résultat du contenu est servi à partir de contoso.com/bar/1.jpg depuis l’origine.
Conserver le chemin d’accès sans correspondance
Le fait de conserver le chemin d’accès sans correspondance vous permet de contrôler la façon dont le chemin restant après le modèle source est géré. En définissant Conserver le chemin d’accès sans correspondance sur Oui, le chemin restant est ajouté au nouveau chemin. En revanche, le définir sur Non (valeur par défaut) supprime le chemin restant après le modèle source.
Voici un exemple montrant le comportement de Conserver un chemin d’accès sans correspondance :
| Conserver le chemin d’accès sans correspondance | Modèle source | Destination | Requête entrante | Contenu traité à partir de l’origine |
|---|---|---|---|---|
| Oui | / | /foo/ | contoso.com/sub/1.jpg | /foo/sub/1.jpg |
| Oui | /sub/ | /foo/ | contoso.com/sub/image/1.jpg | /foo/image/1.jpg |
| Non | /sub/ | /foo/2.jpg | contoso.com/sub/image/1.jpg | /foo/2.jpg |
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).
Azure Front Door (classique) prend en charge la réécriture d’URL en configurant un chemin de transfert personnalisé lors de la configuration de la règle de type de routage de transfert. Par défaut, si seule une barre oblique (/*) est définie, Front Door réplique le chemin d’URL entrant dans la requête transférée. L’en-tête d’hôte utilisé dans la requête transférée repose sur la configuration du backend sélectionné. Pour plus d’informations, consultez la documentation En-tête de l’hôte backend.
L’aspect clé de la réécriture d’URL réside dans la possibilité de copier une partie correspondante du chemin entrant vers le chemin transféré lors de l’utilisation d’un chemin de transfert personnalisé avec une correspondance générique. Le tableau suivant illustre un exemple de requête entrante et le chemin d’accès transféré correspondant lors de l’utilisation d’un chemin de transfert personnalisé de /fwd/. La section indiquée sous la forme a/b/c représente la partie qui remplace la correspondance générique.
| Chemin d’URL entrant | Chemin de correspondance | Chemin de transfert personnalisé | Chemin transféré |
|---|---|---|---|
| /foo/a/b/c | /foo/* | /fwd/ | /fwd/a/b/c |
Exemple de réécriture d’URL
Prenons l’exemple d’une règle d’acheminement avec la combinaison suivante d’hôtes front-end et de chemins configurés :
| Hôtes | Chemins |
|---|---|
| www.contoso.com | /* |
| /foo | |
| /foo/* | |
| /foo/bar/* |
Le tableau suivant illustre des exemples de requêtes entrantes et leurs itinéraires correspondants les plus spécifiques. Il fournit également des exemples de chemins de transfert personnalisés et les chemins transférés résultants.
Par exemple, considérez la deuxième ligne du tableau. Si la requête entrante est www.contoso.com/sub, et que le chemin de transfert personnalisé est défini sur /, le chemin transféré est /sub. Toutefois, si le chemin de transfert personnalisé est défini sur /fwd/, le chemin transféré est /fwd/sub. Les parties en gras des chemins représentent les éléments qui font partie de la mise en correspondance générique.
| Requête entrante | Chemin correspondant le plus spécifique | / | /fwd/ | /foo/ | /foo/bar/ |
|---|---|---|---|---|---|
| www.contoso.com/ | /* | / | /fwd/ | /foo/ | /foo/bar/ |
| www.contoso.com/sub | /* | /sub | /fwd/sub | /foo/sub | /foo/bar/sub |
| www.contoso.com/a/b/c | /* | /a/b/c | /fwd/a/b/c | /foo/a/b/c | /foo/bar/a/b/c |
| www.contoso.com/foo | /foo | / | /fwd/ | /foo/ | /foo/bar/ |
| www.contoso.com/foo/ | /foo/* | / | /fwd/ | /foo/ | /foo/bar/ |
| www.contoso.com/foo/bar | /foo/* | /bar | /fwd/bar | /foo/bar | /foo/bar/bar |
Notes
Azure Front Door (classique) prend uniquement en charge la réécriture d’URL à partir d’un chemin statique vers un autre chemin statique. La conservation du chemin d’accès sans correspondance est prise en charge avec Azure Front Door Standard et Premium. Pour plus d’informations, consultez Conserver le chemin d’accès sans correspondance.
Paramètres facultatifs
Configuration du cache : si vous désactivez ou ne spécifiez pas ce paramètre, les requêtes qui correspondent à cette règle d’acheminement ne tentent pas d’utiliser le contenu mis en cache, mais elles extraient toujours à partir du back-end. Pour plus d’informations, consultez l’article Mise en cache avec Azure Front Door.
Étapes suivantes
- Découvrez comment Créer un profil Azure Front Door.
- Découvrez-en plus sur l’ensemble de règles Azure Front Door.
- Découvrez-en plus sur l’architecture de routage d’Azure Front Door.