Réécrire des en-têtes HTTP et une URL à l’aide d’Application Gateway
Application Gateway vous permet de réécrire certains contenus de requêtes et de réponses. Avec cette fonctionnalité, vous pouvez traduire des URL, interroger des paramètres de chaîne et modifier des en-têtes de requête et de réponse. Elle vous permet également d’ajouter des conditions assurant que l’URL ou les en-têtes spécifiés sont réécrits uniquement quand 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 d'en-tête HTTP et d'URL ne sont disponibles que 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 à un serveur de transmettre des informations supplémentaires avec une requête ou une réponse. En réécrivant ces en-têtes, vous pouvez effectuer des tâches importantes, comme ajouter des champs d’en-tête liés à la sécurité comme HSTS/X-XSS-Protection, supprimer des champs d’en-tête de réponse susceptibles de révéler des informations sensibles et supprimer les informations de port des en-têtes X-Forwarded-For.
Vous pouvez réécrire tous les en-têtes des requêtes et des 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 demandes et réponses acheminées via celle-ci. Pour savoir comment réécrire des en-têtes de requête et de réponse avec Application Gateway à l’aide du portail Azure, consultez cette page.
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 et la chaîne de requête de l’URL de requête.
Choisir de réécrire l’URL de toutes les requêtes sur un écouteur ou uniquement des requêtes qui correspondent à une ou plusieurs des conditions que vous avez définies. 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 une URL avec Application Gateway à l’aide du portail Azure, consultez cette page.
Comprendre les réécritures dans Application Gateway
Un ensemble de réécriture est une collection d'une règle d’acheminement, d'une condition et d'une action.
Association de règles d’acheminement des demandes : La configuration de réécriture est associée à un écouteur source via sa règle de routage. Lorsque vous utilisez une règle d’acheminement de type Basic, la configuration de réécriture est associée à son écouteur et fonctionne comme une réécriture globale. Lorsque vous utilisez une règle d’acheminement basée sur le chemin, la configuration de réécriture est définie selon la carte de chemin 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 d’acheminement, mais une règle de routage ne peut avoir qu'une seule réécriture associée.
Réécrire la condition : Il s'agit d'une configuration facultative. En fonction des conditions que vous définissez, Azure Application Gateway évaluera le contenu des requêtes et des réponses HTTP(S). L'« action de réécriture » suivante se produira 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 les conditions de réécriture pour évaluer le contenu des requêtes et les réponses HTTP(S). Cette configuration facultative vous permet d’effectuer une réécriture uniquement quand 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 de serveur prises en charge
Une condition vous permet d'évaluer si un en-tête ou une variable spécifié existe en faisant correspondre leurs valeurs via du texte ou un modèle Regex. Pour les configurations de réécriture avancées, vous pouvez également capturer la valeur de l'en-tête ou de la variable du serveur pour une utilisation ultérieure sous Action de réécriture. En savoir plus sur le modèle et la capture.
Action de réécriture : L'ensemble d'actions de réécriture vous permet de réécrire les en-têtes (requête ou réponse) ou les composants de l'URL.
Une action peut avoir les types de valeur suivants ou leurs combinaisons :
- Text.
- Valeur de l’en-tête de demande – Pour utiliser une valeur d’en-tête de demande capturée, spécifiez la syntaxe
{http_req_headerName}. - Valeur de l’en-tête de réponse – Pour utiliser une valeur d’en-tête de réponse capturée de la condition précédente, spécifiez la syntaxe
{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 ainsi que 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 comme
{var_serverVariable}. Liste des variables de 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 devrez continuer à utiliser une méthode autre que le portail pour toutes les opérations PUT, si vous utilisez ce champ.
Lors de l'utilisation d'une action pour réécrire une URL, les opérations suivantes sont prises en charge :
- Chemin URL : la nouvelle valeur à définir comme chemin.
- Chaîne de requête URL : la nouvelle valeur vers laquelle la chaîne de requête doit être réécrite.
- Réévaluez la carte de chemin : spécifiez si la carte de chemin d'URL doit être réévaluée après la réécriture. Si cette option est désactivée, le chemin d’URL d’origine est utilisé pour la correspondance avec le chemin de modèle dans le mappage du chemin d’URL. Si la valeur est true, le mappage du chemin d’URL est réévalué pour que la correspondance avec le chemin réécrit soit vérifiée. L’activation de ce commutateur permet de router la requête vers un autre pool de back-ends après la réécriture.
Recherche et capture de modèles
La correspondance et la capture de modèles sont prises en charge sous Condition et Action (sous Action, elles sont prises en charge uniquement pour un en-tête spécifique).
Critères spéciaux
Application Gateway utilise des expressions régulières pour la recherche de modèles. Vous devez utiliser des expressions compatibles avec les expressions régulières 2 (RE2) lors de l'écriture de votre syntaxe de correspondance de modèles.
Vous pouvez utiliser la correspondance de modèle à la fois sous Condition et sous Action.
- Condition : Ceci est utilisé pour faire correspondre les valeurs d'un en-tête ou d'une variable de serveur. Pour faire correspondre un modèle sous « Conditions », utilisez la propriété « modèle ».
- Action : La correspondance de modèle sous Action Set n'est disponible que pour l'en-tête de réponse « Set-Cookie ». Pour faire correspondre un modèle pour Set-Cookie sous une action, utilisez la propriété « HeaderValueMatcher ». Si elle est capturée, sa valeur peut être utilisée comme {capt_header_value_matcher}. Comme il peut y avoir plusieurs Set-Cookie, une correspondance de modèle ici vous permet de rechercher un cookie spécifique. Exemple : pour une certaine version de l'agent utilisateur, vous souhaitez réécrire l'en-tête de réponse set-cookie pour « cookie2 » avec max-age=3600 (une heure). Dans ce cas, vous pouvez utiliser
- Condition - Type : En-tête de requête, Nom d'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 : Ensemble, Nom d'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 Web Application Firewall ( WAF) Application Gateway avec l’ensemble de règles de base 3.1 ou une version antérieure, vous pouvez rencontrer des problèmes lors de l’utilisation d’expressions régulières compatibles avec Perl (PCRE) lors de l’exécution d’assertions avant et arrière (négatives ou positives).
Syntaxe pour la capture
Les modèles peuvent également être utilisés pour capturer une sous-chaîne pour une utilisation ultérieure. Mettez des parenthèses autour d’un sous-modèle 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 continue simplement de définir des variables numérotées pour vous afin de représenter ces chaînes capturées. Vous pouvez trouver 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 de l'ensemble d'actions en utilisant le 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 / comme préfixe et suffixe du modèle ne doit pas être spécifiée dans le modèle pour correspondre à la valeur. 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 que user-agent, ma variable de capture doit être pour user-agent (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 de 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 requête client, la variable add_x_forwarded_for_proxy est égale à la variable $client_ip. Cette variable est utile quand vous voulez réécrire l’en-tête X-Forwarded-For défini par Application Gateway pour 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 devant la passerelle d’application et le client d’origine, client_ip retourne 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. Par exemple, dans la requête http://contoso.com:8080/article.aspx?id=123&title=fabrikam, la valeur hôte 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 de paires variable/valeur qui suivent le « ? » dans l’URL demandée. Par 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). Par 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 requête 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 serveur de la même façon que ci-dessus avec les autres variables 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:<raison> ou NONE en l’absence de certificat. |
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 : des clients ont été initialement redirigés vers un chemin tel que « /blog », mais ils doivent à présent être envoyés vers « /updates » en raison d’un changement dans la structure du contenu.
Avertissement
La nécessité de modifier une URL de redirection peut parfois se présenter dans le contexte d’une configuration où Application Gateway est configuré pour remplacer le nom d’hôte pour le back-end. Le nom d’hôte tel qu’il est vu le back-end est dans ce cas différent de celui perçu par le navigateur. Dans ce cas, la redirection n’utilise pas le nom d’hôte approprié. Cette configuration n’est pas recommandée.
Les limitations et les implications d’une configuration de ce type sont décrites dans Conserver le nom d’hôte HTTP d’origine entre un proxy inverse et son application web de back-end. La configuration recommandée pour App Service consiste à suivre les instructions pour « Domaine personnalisé (recommandé) » dans Configurer App Service avec Application Gateway. La réécriture de l’en-tête Location dans la réponse, comme décrit dans l’exemple ci-dessous, doit être considérée comme une solution de contournement qui n’agit pas sur 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. Le client adresse donc la requête directement à contoso.azurewebsites.net/path2 au lieu de passer par la passerelle applicative (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 :
Créez une règle de réécriture avec une condition qui détermine si l’en-tête d’emplacement de la réponse contient azurewebsites.net. Entrez le modèle
(https?):\/\/.*azurewebsites\.net(.*)$.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. Pour ce faire, entrez
{http_resp_Location_1}://contoso.com{http_resp_Location_2}comme valeur d’en-tête. Vous pouvez également utiliser la variable de serveurhostpour 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 :
Il n’est pas possible de créer une 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 pour supprimer et l’en-tête défini sur l’hôte, une erreur se produit.
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 les scénarios dans lesquels vous souhaitez choisir le pool de back-ends en fonction de la valeur d’un en-tête, d’une partie de l’URL ou d’une chaîne de requête, vous pouvez utiliser conjointement la fonctionnalité de réécriture d’URL et le routage basé sur le chemin.
Pour ce faire, créez un jeu de réécriture avec une condition qui recherche un paramètre spécifique (chaîne de requête, en-tête, etc.), puis effectue une action où elle change le chemin d’URL (vérifiez que Réévaluer le mappage de chemin est activé). Le jeu de réécriture doit ensuite être associé à une règle basée sur le chemin. La règle basée sur le chemin doit contenir les mêmes chemins d’URL spécifiés dans le jeu de réécriture et leur pool de back-ends correspondant.
Ainsi, le jeu de réécriture permet aux utilisateurs de rechercher un paramètre spécifique et de l’affecter à un nouveau chemin, et la règle basée sur le chemin permet aux utilisateurs d’affecter des pools de back-ends à ces chemins. Tant que « Réévaluer le mappage de chemin » est activé, le trafic est routé en fonction du chemin spécifié dans le jeu de réécriture.
Pour obtenir un exemple de cas d’usage utilisant des chaînes de requête, consultez Router le trafic avec la sélection de chemin basé sur un paramètre dans le portail.
Réécrire les paramètres de chaîne de requête en fonction de l’URL
Prenons l’exemple d’un site web de commerce en ligne. Le lien visible par l’utilisateur doit être simple et lisible, mais le serveur back-end a besoin des paramètres de la chaîne de requête pour afficher le contenu approprié.
Dans ce cas, Application Gateway peut capturer les paramètres à partir de l’URL et ajouter les paires clé-valeur de la chaîne de requête à partir de celles de l’URL. Par exemple, supposons que l’utilisateur souhaite réécrire https://www.contoso.com/fashion/shirts en https://www.contoso.com/buy.aspx?category=fashion&product=shirts. Pour cela, il peut utiliser la configuration de réécriture d’URL suivante.
Condition - Si la variable de serveur uri_path correspond 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 obtenir un guide pas à pas permettant de réaliser le scénario décrit ci-dessus, consultez Réécriture d’URL avec Azure Application Gateway – Portail Azure.
Erreurs courantes lors de la réécriture de la configuration
L’activation de l’option « Réévaluer le mappage de chemin d’accès » n’est pas autorisée pour les règles d’acheminement de requête de base. Cela permet d’éviter une boucle d’évaluation infinie pour une règle de routage de base.
Vous devez activer au moins une règle de réécriture conditionnelle ou une règle de réécriture qui n’a pas la valeur « Réévaluer le mappage de chemin d’accès » pour les règles de routage basées sur le chemin, afin d’empêcher une boucle d’évaluation infinie pour une règle d’acheminement basée sur le chemin d’accès.
Les requêtes entrantes se termineraient par un code d’erreur 500 au cas où une boucle serait créée dynamiquement en fonction des entrées du client. La passerelle applicative continue à traiter les autres requêtes sans dégradation dans un tel 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)
Quand vous configurez la réécriture d’URL ou la réécriture d’en-tête d’hôte, l’évaluation du WAF se produit après la modification de l’en-tête de la requête ou des paramètres d’URL (après réécriture). Et lorsque vous supprimez la configuration de réécriture d’URL ou de réécriture de l’en-tête de l’hôte sur votre instance Application Gateway, l’évaluation du WAF est effectuée avant la réécriture de l’en-tête. Cet ordre permet de s’assurer que les règles de WAF sont appliquées à la dernière requête reçue par votre pool principal.
Par exemple, imaginons que vous avez 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éécrivez la valeur en "image/png".
Ici, avec seulement la réécriture d’en-tête configurée, l’évaluation WAF est effectuée 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 du WAF est effectuée sur "Accept" : "image/png".
Réécriture d’URL et redirection d’URL
Dans le cadre d’une réécriture d’URL, Application Gateway réécrit l’URL avant que la requête ne soit envoyée au back-end. Cela ne change rien à ce que les utilisateurs voient dans le navigateur. En effet, les modifications sont masquées pour l’utilisateur.
Dans le cadre d’une redirection d’URL, Application Gateway envoie une réponse de redirection au client avec la nouvelle URL. Ceci oblige alors le client à renvoyer sa requête à la nouvelle URL fournie dans la redirection. L’URL que l’utilisateur(-trice) 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êtes contenant d’autres caractères sont ignorés lorsqu’une demande est envoyée à la cible back-end.
- Les noms d’en-tête de réponse peuvent contenir n’importe quel caractère alphanumérique et des symboles spécifiques tels que définis dans RFC 7230.
- Les en-têtes de connexion et de mise à niveau ne peuvent pas être réécrits.
- 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