Réécrire des en-têtes HTTP et une URL à l’aide d’Application Gateway

Application Gateway vous permet de réécrire le contenu sélectionné dans les requêtes et les réponses. Avec cette fonctionnalité, vous pouvez traduire des URL, des paramètres de chaîne de requête et modifier des en-têtes de requête et de réponse. Vous pouvez également ajouter des conditions pour vous assurer que l’URL ou les en-têtes spécifiés sont réécrits uniquement lorsque certaines conditions sont remplies. Ces conditions sont basées sur les informations de requête et de réponse.

Les fonctionnalités de réécriture des en-têtes HTTP et des URL sont uniquement disponibles pour le SKU Application Gateway v2.

En-têtes de requête et de réponse

Application Gateway vous permet d’ajouter, de supprimer et de mettre à jour les en-têtes de requête et de réponse HTTP pendant le déplacement des paquets de requête et de réponse entre le pool client et le pool de back-ends. Les en-têtes HTTP permettent à un client et au serveur de transmettre des informations supplémentaires avec une demande ou une réponse. En réécritant ces en-têtes, vous pouvez accomplir des tâches importantes, notamment :

• Ajout de champs d’en-tête liés à la sécurité tels que HSTS et X-XSS-Protection
• Suppression des champs d’en-tête de réponse susceptibles de révéler des informations sensibles
• Suppression des informations de port des en-têtes X-Forwarded-For

Vous pouvez réécrire tous les en-têtes dans les requêtes et réponses, à l'exception des en-têtes Connection et Upgrade. Vous pouvez également utiliser la passerelle d'application pour créer des en-têtes personnalisés et les ajouter aux requêtes et réponses routées via celle-ci. Pour savoir comment réécrire les en-têtes de demande et de réponse avec Application Gateway à l’aide du portail Azure, consultez ici.

Chemin et chaîne de requête de l’URL

Avec la fonctionnalité de réécriture d’URL d’Application Gateway, vous pouvez :

• Réécrire le nom d’hôte, le chemin d’accès et la chaîne de requête de l’URL de requête

• Choisissez de réécrire l'URL de toutes les requêtes sur un écouteur, ou uniquement celles qui correspondent à une ou plusieurs des conditions que vous définissez. Ces conditions sont basées sur les propriétés de requête (en-tête de demande et variables de serveur).

• Choisir de router la requête (en sélectionnant le pool de back-ends) en fonction de l’URL d’origine ou de l’URL réécrite.

Pour savoir comment réécrire l’URL avec Application Gateway à l’aide du portail Azure, consultez ici.

Comprendre les réécritures dans l'Application Gateway

Un ensemble de réécriture est une collection d’une règle de routage, d’une condition et d’une action.

• Association de règle de routage des requêtes : la configuration de réécriture s'associe à un écouteur source via sa règle de routage. Lorsque vous utilisez une règle de routage de type Basic, la configuration de réécriture s’associe au logiciel d'écoute et fonctionne en tant que réécriture générale. Lorsque vous utilisez une règle de routage basée sur le chemin d’accès, vous définissez la configuration de réécriture en fonction de la carte du chemin d’accès d’URL. Dans ce dernier cas, elle s'applique uniquement à une zone de chemin spécifique d'un site. Vous pouvez appliquer un ensemble de réécriture à plusieurs règles de routage, mais une règle de routage ne peut avoir qu'une seule opération de réécriture associée.

• Condition de réécriture : Cette configuration est facultative. En fonction des conditions que vous définissez, Application Gateway évalue le contenu des requêtes et réponses HTTP(S). L'« action de réécriture » suivante se produit si la requête ou la réponse HTTP(S) correspond à cette condition. Si vous associez plusieurs conditions à une action, cette dernière ne se produit que lorsque toutes les conditions sont remplies. En d’autres termes, il s’agit d’une opération AND logique. Vous pouvez utiliser des conditions de réécriture pour évaluer le contenu des requêtes et réponses HTTP(S). Cette configuration facultative vous permet d'effectuer une réécriture uniquement lorsque une ou plusieurs conditions sont remplies. La passerelle d’application utilise ces types de variables pour évaluer le contenu des requêtes et des réponses :

  Vous pouvez choisir les types suivants pour rechercher une condition :

  • En-tête HTTP (requête et réponse)
  • Variables serveur prises en charge

  Une condition vous permet d’évaluer si un en-tête ou une variable spécifié existe en correspondant à leurs valeurs via du texte ou un modèle Regex. Pour les configurations de réécriture avancées, vous pouvez également capturer la valeur d'un en-tête ou d'une variable serveur pour une utilisation ultérieure dans Action de réécriture. En savoir plus sur le modèle et la capture.

• Réécrire l’action : Le jeu d’actions de réécriture vous permet de réécrire les en-têtes (demande ou réponse) ou les composants d’URL.

  Une action peut avoir les types de valeurs suivants, ou leurs combinaisons :

  • Texte.
  • Valeur de l’en-tête de requête : pour utiliser la valeur de l’en-tête de requête capturée, spécifiez la syntaxe en tant que {http_req_headerName}.
  • Valeur de l’en-tête de réponse : pour utiliser la valeur d’un en-tête de réponse capturé à partir de la condition précédente, spécifiez la syntaxe en tant que {http_resp_headerName}. Le bloc Action de réécriture prend également en charge le champ « Header Value Matcher » pour l'en-tête Set-Cookie. Ce champ facultatif vous permet de faire correspondre et de capturer la valeur d’un en-tête spécifique lorsque plusieurs en-têtes Set-Cookie portant le même nom existent. Pour manipuler la valeur capturée de ce cookie spécifique, vous pouvez ensuite utiliser {capt_header_value_matcher}. En savoir plus sur la capture sous ensemble d’actions.
  • Variable serveur : Pour utiliser une variable serveur, spécifiez la syntaxe {var_serverVariable}. Liste des variables serveur prises en charge.

Remarque

L'utilisation du champ Header Value Matcher {capt_header_value_matcher} n'est actuellement pas prise en charge via le portail. Par conséquent, vous devez utiliser une méthode non-portail pour toutes les opérations PUT si vous utilisez ce champ.

Lorsque vous utilisez une action pour réécrire une URL, les opérations suivantes sont prises en charge :

• Chemin d’URL : nouvelle valeur à définir comme chemin d’accès.
• Chaîne de requête d'URL : nouvelle valeur vers laquelle la chaîne de requête doit être réécrite.
• Réévaluer le mappage de chemin : indique si le mappage de chemin d'URL doit être réévalué après la réécriture. Si vous ne cochez pas cette option, le chemin d’URL d’origine est utilisé pour correspondre au modèle de chemin dans le mappage de chemin d’URL. Si vous définissez cette option sur true, la carte du chemin d’accès d’URL est réévaluée pour vérifier la correspondance avec le chemin réécrit. L’activation de ce commutateur permet de router la requête vers un autre pool de back-ends après la réécriture.

Correspondance et capture de modèles

Application Gateway prend en charge la mise en correspondance des modèles et la capture sous Condition et Action. Sous Action, il prend en charge la mise en correspondance des modèles et la capture uniquement pour un en-tête spécifique.

Critères spéciaux

Application Gateway utilise des expressions régulières pour la correspondance de modèles. Utilisez des expressions compatibles avec l’expression régulière 2 (RE2) lors de l’écriture de votre syntaxe de correspondance de modèle.

Vous pouvez utiliser la correspondance de modèles à la fois dans Condition et dans Action.

• Condition : utilisez ce paramètre pour correspondre aux valeurs d’une variable d’en-tête ou de serveur. Pour faire correspondre un modèle sous « Conditions », utilisez la propriété « pattern ».
• Action : la mise en correspondance des modèles sous Jeu d’actions est disponible uniquement pour l’en-tête Set-Cookiede réponse. Pour faire correspondre un modèle sous Set-Cookie dans le cadre d'une action, utilisez la propriété HeaderValueMatcher. Si elle est capturée, sa valeur peut être utilisée en tant que {capt_header_value_matcher}. Étant donné qu’il peut y avoir plusieurs Set-Cookie en-têtes, le modèle correspondant ici vous permet de rechercher un cookie spécifique. Par exemple, pour une certaine version de l’agent utilisateur, vous souhaitez réécrire l’en-tête set-cookie de réponse avec cookie2max-age=3600 (une heure). Dans ce cas, vous pouvez utiliser
  • Condition : Type : en-tête de requête, Nom de l'en-tête : user-agent, Modèle à faire correspondre : *2.0
  • Action - Type de réécriture : en-tête de réponse, type d’action : Définir, Nom de l’en-tête : Set-Cookie, Correspondance de valeur d’en-tête : cookie2=(.*), Valeur d’en-tête : cookie2={capt_header_value_matcher_1};Max-Age=3600

Remarque

Si vous exécutez un pare-feu d’applications web Application Gateway (WAF) avec l’ensemble de règles de base 3.1 ou une version antérieure, vous risquez de rencontrer des problèmes lors de l’utilisation d’expressions régulières compatibles perl (PCRE) lors de l’exécution d’assertions lookahead et lookbehind (négatives ou positives).

Syntaxe de capture

Vous pouvez utiliser des modèles pour capturer une sous-chaîne pour une utilisation ultérieure. Encadrez un sous-modèle par des parenthèses dans la définition de l'expression régulière. La première paire de parenthèses stocke sa sous-chaîne dans le groupe 1, la deuxième paire dans le groupe 2 et ainsi de suite. Vous pouvez utiliser autant de parenthèses que vous le souhaitez. Perl définit plus de variables numérotées pour représenter ces chaînes capturées. Vous trouverez quelques exemples dans ce guide de programmation Perl.

• (\d)(\d) # Deux chiffres correspondants, capturés dans les groupes 1 et 2
• (\d+) # Un ou plusieurs chiffres correspondants, capturés dans le groupe 1
• (\d)+ # Un chiffre correspondant une ou plusieurs fois, le dernier étant capturé dans le groupe 1

Une fois capturés, vous pouvez les utiliser dans la valeur définie de l'action au format suivant :

• Pour une capture d’en-tête de requête, vous devez utiliser {http_req_headerName_groupNumber}. Par exemple, {http_req_User-Agent_1} ou {http_req_User-Agent_2}.
• Pour une capture d’en-tête de réponse, vous devez utiliser {http_resp_headerName_groupNumber}. Par exemple, {http_resp_Location_1} ou {http_resp_Location_2}. Alors que, pour un en-tête de réponse Set-Cookie capturé via la propriété « HeaderValueMatcher », vous devez utiliser {capt_header_value_matcher_groupNumber}. Par exemple, {capt_header_value_matcher_1} ou {capt_header_value_matcher_2}.
• Pour une variable de serveur, vous devez utiliser {var_serverVariableName_groupNumber}. Par exemple, {var_uri_path_1} ou {var_uri_path_2}.

Remarque

• L'utilisation de / pour préfixer et suffixer le modèle ne doit pas être spécifiée dans la valeur du modèle à faire correspondre. Par exemple, (\d)(\d) correspondra à deux chiffres. /(\d)(\d)/ ne correspond pas à deux chiffres.
• La casse de la variable de condition doit correspondre à celle de la variable de capture. Par exemple, si ma variable de condition est User-Agent, ma variable de capture doit être pour User-Agent (c’est-à-dire {http_req_User-Agent_2}). Si ma variable de condition est définie en tant qu’agent utilisateur, ma variable de capture doit être pour l’agent utilisateur (c’est-à-dire {http_req_user-agent_2}).
• Si vous souhaitez utiliser la valeur entière, vous ne devez pas mentionner le nombre. Utilisez simplement le format {http_req_headerName}, etc. sans groupNumber.

Variables de serveur

Application Gateway utilise des variables de serveur pour stocker des informations utiles sur le serveur, la connexion avec le client et la requête active sur la connexion. L’adresse IP du client et le type de navigateur web sont quelques exemples d’informations stockées. Les variables de serveur changent dynamiquement, par exemple, quand une nouvelle page est chargée ou qu’un formulaire est posté. Vous pouvez utiliser ces variables pour évaluer les conditions de réécriture et réécrire des en-têtes. Pour utiliser la valeur des variables serveur afin de réécrire des en-têtes, vous devez spécifier ces variables dans la syntaxe {var_serverVariableName}

Application Gateway prend en charge les variables de serveur suivantes :

Nom de la variable	Description
add_x_forwarded_for_proxy	Champ d’en-tête de requête client X-Forwarded-For auquel la variable client_ip (voir l’explication plus loin dans ce tableau) est ajoutée au format IP1, IP2, IP3 et ainsi de suite. Si le champ X-Forwarded-For ne se trouve pas dans l’en-tête de la requête cliente, la variable add_x_forwarded_for_proxy est égale à la variable $client_ip. Cette variable est utile lorsque vous souhaitez réécrire l'en-tête X-Forwarded-For défini par Application Gateway afin que l'en-tête contienne uniquement l'adresse IP, sans les informations de port.
ciphers_supported	Liste de chiffrements pris en charge par le client.
ciphers_used	Chaîne de chiffrements utilisés pour une connexion TLS établie.
client_ip	Adresse IP du client à partir duquel la passerelle d’application a reçu la requête. S'il existe un proxy inverse entre la passerelle d'application et le client d'origine, client_ip renvoie l'adresse IP du proxy inverse.
client_port	Port client.
client_tcp_rtt	Informations sur la connexion TCP cliente. Disponible sur les systèmes qui prennent en charge l’option de socket TCP_INFO.
client_user	Quand l’authentification HTTP est utilisée, nom d’utilisateur fourni pour l’authentification.
host	Dans cet ordre de priorité : nom d’hôte de la ligne de la requête, nom d’hôte du champ d’en-tête de requête d’hôte ou nom de serveur correspondant à une requête. Exemple : dans la requête http://contoso.com:8080/article.aspx?id=123&title=fabrikam, la valeur host est contoso.com
cookie_name	Cookie name.
http_method	Méthode utilisée pour effectuer la requête d’URL. Par exemple, GET ou POST.
HTTP_STATUS	État de session. Par exemple, 200, 400 ou 403.
http_version	Protocole de requête. Généralement, HTTP/1.0, HTTP/1.1 ou HTTP/2.0.
query_string	Liste des paires variable/valeur qui suivent l’URL ? demandée. Exemple : dans la requête http://contoso.com:8080/article.aspx?id=123&title=fabrikam, la valeur query_string est id=123&title=fabrikam
received_bytes	Longueur de la requête (incluant la ligne, l’en-tête et le corps de la requête).
request_query	Arguments dans la ligne de la requête.
request_scheme	Schéma de requête : « http » ou « https ».
request_uri	URI complet de la requête d’origine (avec les arguments). Exemple : dans la requête http://contoso.com:8080/article.aspx?id=123&title=fabrikam*, la valeur request_uri est /article.aspx?id=123&title=fabrikam
sent_bytes	Nombre d’octets envoyés à un client.
server_port	Port du serveur qui a accepté une requête.
ssl_connection_protocol	Protocole d’une connexion TLS établie.
ssl_enabled	Valeur « On » si la connexion opère en mode TLS. Sinon, chaîne vide.
uri_path	Identifie la ressource spécifique dans l’hôte à laquelle le client web souhaite accéder. La variable fait référence au chemin d’URL d’origine avant toute manipulation. Il s’agit de la partie de l’URI de demande sans les arguments. Par exemple, dans la requête http://contoso.com:8080/article.aspx?id=123&title=fabrikam, la valeur uri_path est /article.aspx.

Variables de serveur d’authentification mutuelle

Application Gateway prend en charge les variables de serveur suivantes pour les scénarios d’authentification mutuelle. Utilisez ces variables de serveur comme vous le feriez pour d’autres variables de serveur.

Nom de la variable	Description
client_certificate	Le certificat client au format PEM pour une connexion SSL établie.
client_certificate_end_date	Date de fin du certificat client.
client_certificate_fingerprint	Empreinte digitale SHA1 du certificat client pour une connexion SSL établie.
client_certificate_issuer	Chaîne « DN d’émetteur » du certificat client pour une connexion SSL établie.
client_certificate_serial	Numéro de série du certificat client pour une connexion SSL établie.
client_certificate_start_date	Date de début du certificat client.
client_certificate_subject	Chaîne « DN de sujet » du certificat client pour une connexion SSL établie.
client_certificate_verification	Résultat de la vérification du certificat client : SUCCESS, FAILED :<reason> ou NONE si un certificat n’était pas présent.

Scénarios courants de réécriture d’en-tête

Supprimer les informations de port de l’en-tête X-Forwarded-For

Application Gateway insère un en-tête X-Forwarded-For dans toutes les requêtes avant de les transférer au back-end. Cet en-tête est une liste sont séparées par des virgules de ports IP. Dans certains scénarios, les serveurs back-end n’exigent pas que les en-têtes contiennent des adresses IP. Vous pouvez utiliser la réécriture d’en-tête pour supprimer les informations de port de l’en-tête X-Forwarded-For. Une façon d’y parvenir est de définir l’en-tête sur la variable de serveur add_x_forwarded_for_proxy. Vous pouvez également utiliser la variable client_ip :

Modifier une URL de redirection

La modification d’une URL de redirection peut être utile dans certaines circonstances. Par exemple, vous pouvez rediriger les clients vers un chemin d’accès tel que « /blog », mais vous souhaitez maintenant les envoyer à « /updates » en raison d’un changement de structure de contenu.

Avertissement

Vous devrez peut-être modifier une URL de redirection lorsque vous configurez Application Gateway pour remplacer le nom d’hôte vers le serveur principal. Dans cette configuration, le serveur principal voit un nom d’hôte différent du navigateur. La redirection n’utilise pas le nom d’hôte correct. Cette configuration n’est pas recommandée.

Pour plus d’informations sur les limitations et les implications de cette configuration, consultez Conserver le nom d’hôte HTTP d’origine entre un proxy inverse et son application web back-end. Pour obtenir la configuration recommandée pour App Service, consultez « Domaine personnalisé (recommandé) » dans Configurer App Service avec Application Gateway. La réécriture de l’en-tête d’emplacement sur la réponse, comme décrit dans l’exemple suivant, doit être considérée comme une solution de contournement et ne traite pas la cause racine.

Quand le service d’application envoie une réponse de redirection, il utilise le nom d’hôte qui figure dans l’en-tête d’emplacement de sa réponse, qui est identique à celui situé dans la requête qu’il reçoit de la passerelle d’application. Ainsi, le client effectue la requête directement vers contoso.azurewebsites.net/path2 au lieu de passer par la passerelle d'application (contoso.com/path2). Or, il n’est pas souhaitable de contourner la passerelle d’application.

Vous pouvez résoudre ce problème en définissant le nom d’hôte de l’en-tête d’emplacement sur le nom de domaine de la passerelle d’application.

Voici les étapes à suivre pour remplacer le nom d’hôte :

1. Créez une règle de réécriture avec une condition qui vérifie si l’en-tête d’emplacement de la réponse contient azurewebsites.net. Entrez le modèle `(https ?)://azurewebsites.net(.).`

2. Exécutez une action de façon à réécrire l’en-tête d’emplacement et lui attribuer le nom d’hôte de la passerelle d’application. Entrez {http_resp_Location_1}://contoso.com{http_resp_Location_2} comme valeur d’en-tête. Vous pouvez également utiliser la variable de serveur host pour définir le nom d’hôte afin qu’il corresponde à la requête d’origine.

   

Implémenter des en-têtes HTTP de sécurité pour éviter les vulnérabilités

Vous pouvez corriger plusieurs vulnérabilités de sécurité en implémentant les en-têtes nécessaires dans la réponse de l’application. Il s’agit notamment des en-têtes de sécurité X-XSS-Protection, Strict-Transport-Security et Content-Security-Policy. Vous pouvez utiliser Application Gateway pour définir ces en-têtes pour toutes les réponses.

Supprimer les en-têtes indésirables

Vous pouvez souhaiter supprimer les en-têtes d’une réponse HTTP qui présentent des informations sensibles. Par exemple, vous pouvez souhaiter supprimer certaines informations comme les détails concernant le système d’exploitation, la bibliothèque ou le nom du serveur back-end. Vous pouvez utiliser la passerelle d’application pour supprimer ces en-têtes :

Vous ne pouvez pas créer de règle de réécriture pour supprimer l’en-tête de l’hôte. Si vous tentez de créer une règle de réécriture avec le type d'action défini sur supprimer et l'en-tête défini sur host, cela entraîne une erreur.

Vérifier la présence d’un en-tête

Vous pouvez évaluer un en-tête de requête ou de réponse HTTP pour déterminer s’il contient une variable d’en-tête ou de serveur. Cette évaluation est utile si vous voulez procéder à une réécriture d’en-tête qu’en présence d’un certain en-tête.

Scénarios courants de réécriture d’URL

Sélection du chemin en fonction des paramètres

Pour accomplir des scénarios dans lesquels vous souhaitez choisir le pool principal en fonction de la valeur d’un en-tête, d’une partie de l’URL ou d’une chaîne de requête dans la requête, utilisez une combinaison de fonctionnalités de réécriture d’URL et de routage basé sur le chemin d’accès.

Créez un ensemble de réécriture avec une condition qui vérifie un paramètre spécifique (chaîne de requête, en-tête, etc.), puis effectue une action où il modifie le chemin d'URL (vérifiez que Réévaluer le mappage de chemin est activé). Associez le jeu de réécriture à une règle basée sur le chemin d’accès. La règle basée sur le chemin doit contenir les mêmes chemins d'URL que ceux spécifiés dans l'ensemble de réécriture, ainsi que leur pool back-end correspondant.

Ainsi, l'ensemble de réécriture vous permet de vérifier un paramètre spécifique et de lui attribuer un nouveau chemin, et la règle basée sur le chemin vous permet d'attribuer des pools back-end à ces chemins. Tant que « Réévaluer le mappage de chemin » est activé, le trafic est routé en fonction du chemin spécifié dans l'ensemble de réécriture.

Pour un exemple de cas d'utilisation avec des chaînes de requête, consultez Router le trafic en utilisant la sélection de chemin basée sur des paramètres dans le portail.

Réécrire les paramètres de chaîne de requête en fonction de l’URL

Considérez un scénario d’un site web d’achat où le lien visible par l’utilisateur est simple et lisible, mais le serveur principal a besoin des paramètres de chaîne de requête pour afficher le contenu approprié.

Dans ce cas, Application Gateway peut capturer des paramètres à partir de l’URL et ajouter des paires clé-valeur de chaîne de requête à partir de ces paramètres dans l’URL. Par exemple, si l’utilisateur souhaite réécrire https://www.contoso.com/fashion/shirtshttps://www.contoso.com/buy.aspx?category=fashion&product=shirts, vous pouvez atteindre cet objectif via la configuration de réécriture d’URL suivante.

Condition : si la variable uri_path de serveur est égale au modèle /(.+)/(.+)

Action - Définir le chemin d’URL sur buy.aspx et la chaîne de requête sur category={var_uri_path_1}&product={var_uri_path_2}

Pour suivre un guide pas à pas pour réaliser le scénario décrit précédemment, consultez Réécrire l'URL avec Application Gateway en utilisant le portail Azure.

Erreurs courantes lors de la réécriture de la configuration

• Vous ne pouvez pas activer « Réévaluer la carte de chemin d’accès » pour les règles de routage de requête de base. Cette restriction empêche une boucle d’évaluation infinie pour une règle de routage de base.

• Pour les règles de routage basées sur le chemin d’accès, vous avez besoin d’au moins une règle de réécriture conditionnelle ou d’une règle de réécriture sans « Réévaluer la carte de chemin d’accès » activée. Cette exigence empêche une boucle d’évaluation infinie pour une règle de routage basée sur le chemin d’accès.

• Si une boucle est créée dynamiquement en fonction des entrées clientes, les requêtes entrantes se terminent par un code d’erreur 500. Application Gateway continue de traiter d’autres demandes sans dégradation dans ce scénario.

Utilisation de la réécriture d’URL ou de la réécriture d’en-tête de l’hôte avec le pare-feu d’applications web (WAF_v2 SKU)

Lorsque vous configurez la réécriture d'URL ou la réécriture de l'en-tête host, l'évaluation WAF se produit après la modification de l'en-tête de requête ou des paramètres d'URL (post-réécriture). Lorsque vous supprimez la configuration de réécriture d’url ou de réécriture d’en-tête de l’hôte sur votre application Gateway, l’évaluation WAF se produit avant la réécriture de l’en-tête (préécriture). Cet ordre garantit que les règles WAF s’appliquent à la demande finale que votre pool back-end reçoit.

Par exemple, supposons que vous disposiez de la règle de réécriture d’en-tête suivante pour l’en-tête "Accept" : "text/html" : si la valeur de l’en-tête "Accept" est égale à "text/html", réécrire la valeur dans "image/png".

Avec uniquement la réécriture d’en-tête configurée, l’évaluation WAF se produit sur "Accept" : "text/html". Toutefois, lorsque vous configurez la réécriture d’URL ou la réécriture d’en-tête de l’hôte, l’évaluation WAF se produit sur "Accept" : "image/png".

Réécriture d’URL et redirection d’URL

Pour une réécriture d’URL, Application Gateway réécrit l’URL avant d’envoyer la requête au back-end. Cette action ne modifie pas ce que les utilisateurs voient dans le navigateur, car les modifications sont masquées de l’utilisateur.

Dans le cadre d’une redirection d’URL, Application Gateway envoie une réponse de redirection au client avec la nouvelle URL. Cette réponse exige que le client renvoie sa demande à la nouvelle URL fournie dans la redirection. L'URL que l'utilisateur voit dans le navigateur est mise à jour vers la nouvelle URL.

Limites

• Les réécritures ne sont pas prises en charge quand la passerelle d’application est configurée pour rediriger les demandes ou afficher une page d’erreur personnalisée.
• Les noms d’en-tête de demande peuvent contenir des caractères alphanumériques et des traits d’union. Les noms d’en-tête contenant d’autres caractères sont ignorés lorsqu’une requête est envoyée à la cible principale.
• Les noms d'en-tête de réponse peuvent contenir tous les caractères alphanumériques et certains symboles, comme défini dans la RFC 7230.
• Vous ne pouvez pas réécrire X-Original-Host, Connectionet les upgrade en-têtes.
• Les réécritures ne sont pas prises en charge pour les réponses 4xx et 5xx générées directement à partir d’Application Gateway.

Étapes suivantes

• Découvrez comment réécrire des en-têtes HTTP avec Application Gateway à l’aide du portail Azure.
• Découvrez comment réécrire une URL avec Application Gateway à l’aide du portail Azure.