HTTP-headers en URL herschrijven met Application Gateway
Met Application Gateway kunt u geselecteerde inhoud van aanvragen en antwoorden herschrijven. Met deze functie kunt u URL's, queryreeksparameters vertalen en aanvraag- en antwoordheaders wijzigen. Hiermee kunt u ook voorwaarden toevoegen om ervoor te zorgen dat de URL of de opgegeven headers alleen worden herschreven wanneer aan bepaalde voorwaarden wordt voldaan. Deze voorwaarden zijn gebaseerd op de informatie in de aanvraag en het antwoord.
De http-header- en URL-herschrijffuncties zijn alleen beschikbaar voor de Application Gateway v2-SKU.
Aanvraag- en antwoordheaders
Met Application Gateway kunt u HTTP-aanvraag- en antwoordheaders toevoegen, verwijderen of bijwerken terwijl de aanvraag- en antwoordpakketten tussen de client- en back-endpools schakelen. Met HTTP-headers kan een client en server aanvullende informatie doorgeven met een aanvraag of antwoord. Door deze headers te herschrijven, kunt u belangrijke taken uitvoeren, zoals het toevoegen van beveiligingsgerelateerde koptekstvelden zoals HSTS/X-XSS-Protection, het verwijderen van antwoordheadervelden die gevoelige informatie kunnen onthullen en poortgegevens verwijderen uit X-Forwarded-For-headers.
U kunt alle headers in aanvragen en antwoorden herschrijven, met uitzondering van de Connectionen Upgrade headers. U kunt de toepassingsgateway ook gebruiken om aangepaste headers te maken en deze toe te voegen aan de aanvragen en antwoorden die worden gerouteerd. Zie hier voor meer informatie over het herschrijven van aanvraag- en antwoordheaders met Application Gateway met behulp van Azure Portal.
URL-pad en querytekenreeks
Met de mogelijkheid voor het herschrijven van URL's in Application Gateway kunt u het volgende doen:
De hostnaam, het pad en de querytekenreeks van de aanvraag-URL herschrijven
Kies ervoor om de URL van alle aanvragen op een listener te herschrijven of alleen die aanvragen die overeenkomen met een of meer van de voorwaarden die u hebt ingesteld. Deze voorwaarden zijn gebaseerd op de aanvraageigenschappen (aanvraagheader- en servervariabelen).
Kies ervoor om de aanvraag te routeren (selecteer de back-endpool) op basis van de oorspronkelijke URL of de herschreven URL
Zie hier voor meer informatie over het herschrijven van URL's met Application Gateway met behulp van Azure Portal.
Meer informatie over herschrijven in Application Gateway
Een herschrijfset is een verzameling van een routeringsregel, voorwaarde en actie.
Koppeling van routeringsregel aanvragen: de herschrijfconfiguratie is via de routeringsregel gekoppeld aan een bronlistener. Wanneer u een routeringsregel van het type Basic gebruikt, wordt de herschrijfconfiguratie gekoppeld aan de listener en werkt deze als een globale herschrijffunctie. Wanneer u een routeringsregel op basis van een pad gebruikt, wordt de herschrijfconfiguratie gedefinieerd volgens de URL-padtoewijzing. In het laatste geval geldt dit alleen voor een specifiek padgebied van een site. U kunt een herschrijfset toepassen op meerdere routeringsregels, maar aan een routeringsregel kan slechts één herschrijfregel zijn gekoppeld.
Herschrijfvoorwaarde: dit is een optionele configuratie. Op basis van de voorwaarden die u definieert, evalueert Application Gateway de inhoud van de HTTP(S)-aanvragen en -antwoorden. De volgende 'herschrijfactie' vindt plaats als de HTTP(S)-aanvraag of -reactie overeenkomt met deze voorwaarde. Als u meer dan één voorwaarde aan een actie koppelt, treedt de actie alleen op wanneer aan alle voorwaarden wordt voldaan. Met andere woorden, het is een logische AND-bewerking. U kunt herschrijfvoorwaarden gebruiken om de inhoud van HTTP(S)-aanvragen en -antwoorden te evalueren. Met deze optionele configuratie kunt u alleen een herschrijfbewerking uitvoeren wanneer aan een of meer voorwaarden wordt voldaan. De toepassingsgateway gebruikt deze typen variabelen om de inhoud van aanvragen en antwoorden te evalueren:
U kunt de volgende typen kiezen om te zoeken naar een voorwaarde:
- HTTP-header (aanvraag en antwoord)
- Ondersteunde servervariabelen
Met een voorwaarde kunt u evalueren of een opgegeven header of variabele bestaat door de bijbehorende waarden te vergelijken via tekst of een Regex-patroon. Voor geavanceerde herschrijfconfiguraties kunt u ook de waarde van de header- of servervariabele vastleggen voor later gebruik onder Herschrijfactie. Meer informatie over patroon en vastleggen.
Herschrijfactie: met de actieset Herschrijven kunt u headers (aanvraag of antwoord) of de URL-onderdelen herschrijven.
Een actie kan de volgende waardetypen of combinaties hebben:
- Tekst.
- Waarde van aanvraagheader: als u een vastgelegde aanvraagheaderwaarde wilt gebruiken, geeft u de syntaxis op als
{http_req_headerName}. - Waarde van antwoordheader: als u een vastgelegde antwoordheaderwaarde uit de voorgaande voorwaarde wilt gebruiken, geeft u de syntaxis op als
{http_resp_headerName}. U kunt deze gebruiken{capt_header_value_matcher}wanneer de waarde wordt vastgelegd in de antwoordheader 'Set-Cookie' van de actieset. Meer informatie over vastleggen onder Actieset. - Servervariabele: als u een servervariabele wilt gebruiken, geeft u de syntaxis op als
{var_serverVariable}. Lijst met ondersteunde servervariabelen.
Wanneer u een actie gebruikt om een URL te herschrijven, worden de volgende bewerkingen ondersteund:
- URL-pad: De nieuwe waarde die moet worden ingesteld als het pad.
- URL-queryreeks: de nieuwe waarde waarnaar de querytekenreeks moet worden herschreven.
- Padtoewijzing opnieuw evalueren: geef op of de URL-padtoewijzing opnieuw moet worden geëvalueerd na herschrijven. Als dit selectievakje niet is ingeschakeld, wordt het oorspronkelijke URL-pad gebruikt om het padpatroon in de URL-padtoewijzing te vinden. Als dit is ingesteld op true, wordt de URL-padtoewijzing opnieuw geëvalueerd om de overeenkomst met het herschreven pad te controleren. Het inschakelen van deze switch helpt bij het routeren van de aanvraag naar een andere back-endpool na herschrijven.
Patroonkoppeling en vastleggen
Patten matching and capture are supported under Condition and Action (under Action, it wordt only supported for a specific header).
Patroonherkenning
Application Gateway maakt gebruik van reguliere expressies voor patroonkoppeling. U moet regulier expressies 2 (RE2) gebruiken bij het schrijven van de overeenkomende syntaxis van uw patroon.
U kunt patroonkoppeling gebruiken onder voorwaarde en actie.
- Voorwaarde: Dit wordt gebruikt om de waarden voor een header- of servervariabele te vinden. Gebruik de eigenschap Pattern om overeen te komen met een patroon onder Voorwaarden.
- Actie: Patroonkoppeling onder Actieset is alleen beschikbaar voor antwoordheader 'Set-Cookie'. Als u een patroon voor Set-Cookie onder een actie wilt vergelijken, gebruikt u de eigenschap HeaderValueMatcher. Indien vastgelegd, kan de waarde worden gebruikt als {capt_header_value_matcher}. Omdat er meerdere set-cookie kan zijn, kunt u met een patroon dat hier overeenkomt met een specifieke cookie zoeken. Voorbeeld: Voor een bepaalde versie van user-agent wilt u de set-cookie-antwoordheader voor 'cookie2' herschrijven met max-age=3600 (één uur). In dit geval kunt u
- Voorwaarde - Type: Aanvraagheader, headernaam: user-agent, Pattern to match: *2.0
- Actie - Herschrijftype: Antwoordheader, Actietype: Instellen, Koptekstnaam: Set-Cookie, Header Value Matcher: cookie2=(.*), Header value: cookie2={capt_header_value_matcher_1}; Max-Age=3600
Notitie
Als u een Application Gateway Web Application Firewall (WAF) uitvoert met Core Rule Set 3.1 of eerder, kunt u problemen ondervinden bij het gebruik van Perl Compatible Regular Expressions (PCRE) tijdens het uitvoeren van lookahead- en lookbehind-asserties (negatief of positief).
Syntaxis voor vastleggen
Patronen kunnen ook worden gebruikt om een subtekenreeks vast te leggen voor later gebruik. Plaats haakjes rond een subpatroon in de regex-definitie. Het eerste paar haakjes slaat de subtekenreeks op in 1, het tweede paar in 2, enzovoort. U mag zoveel haakjes gebruiken als u wilt; Perl blijft alleen meer genummerde variabelen definiëren om deze vastgelegde tekenreeksen weer te geven. U vindt een voorbeeld in deze Perl-programmeerrichtlijnen.
- (\d)(\d) # Twee cijfers vergelijken, ze vastleggen in groepen 1 en 2
- (\d+) # Een of meer cijfers vergelijken en ze allemaal vastleggen in groep 1
- (\d)+ # Een cijfer een of meer keren vergelijken, waarbij de laatste wordt vastgelegd in groep 1
Zodra deze zijn vastgelegd, kunt u deze gebruiken in de waarde van de actieset met behulp van de volgende indeling:
- Voor een aanvraagheaderopname moet u {http_req_headerName_groupNumber} gebruiken. Bijvoorbeeld {http_req_User-Agent_1} of {http_req_User-Agent_2}
- Voor het vastleggen van een antwoordheader moet u {http_resp_headerName_groupNumber} gebruiken. Bijvoorbeeld {http_resp_Location_1} of {http_resp_Location_2}. Terwijl u {capt_header_value_matcher_groupNumber} moet gebruiken voor een set-cookie voor een antwoordheader die is vastgelegd via de eigenschap HeaderValueMatcher. Bijvoorbeeld {capt_header_value_matcher_1} of {capt_header_value_matcher_2}.
- Voor een servervariabele moet u {var_serverVariableName_groupNumber} gebruiken. Bijvoorbeeld {var_uri_path_1} of {var_uri_path_2}
Notitie
- Gebruik van /om voor- en achtervoegsel het patroon niet te specificeren in het patroon om de waarde te vinden. (\d)(\d) komt bijvoorbeeld overeen met twee cijfers. /(\d)(\d)/ komt niet overeen met twee cijfers.
- Het geval van de voorwaardevariabele moet overeenkomen met het hoofdlettergebruik van de vastlegvariabele. Als mijn voorwaardevariabele bijvoorbeeld User-Agent is, moet mijn capture-variabele voor User-Agent zijn (bijvoorbeeld {http_req_User-Agent_2}). Als mijn voorwaardevariabele is gedefinieerd als user-agent, moet mijn capture-variabele zijn voor user-agent (bijvoorbeeld {http_req_user-agent_2}).
- Als u de hele waarde wilt gebruiken, moet u het getal niet vermelden. Gebruik gewoon de notatie {http_req_headerName}, enzovoort zonder het groupNumber.
Servervariabelen
Application Gateway maakt gebruik van servervariabelen om nuttige informatie op te slaan over de server, de verbinding met de client en de huidige aanvraag voor de verbinding. Voorbeelden van opgeslagen gegevens zijn het IP-adres van de client en het type webbrowser. Servervariabelen worden dynamisch gewijzigd, bijvoorbeeld wanneer een nieuwe pagina wordt geladen of wanneer een formulier wordt geplaatst. U kunt deze variabelen gebruiken om herschrijfvoorwaarden te evalueren en headers te herschrijven. Als u de waarde van servervariabelen wilt gebruiken om headers te herschrijven, moet u deze variabelen opgeven in de syntaxis {var_serverVariableName}
Application Gateway ondersteunt de volgende servervariabelen:
| Variabelenaam | Beschrijving |
|---|---|
| add_x_forwarded_for_proxy | Het veld X-Forwarded-For-clientaanvraag met de client_ip variabele (zie uitleg verderop in deze tabel) toegevoegd in de indeling IP1, IP2, IP3 enzovoort. Als het veld X-Forwarded-For zich niet in de header van de clientaanvraag bevindt, is de add_x_forwarded_for_proxy variabele gelijk aan de $client_ip variabele. Deze variabele is handig als u de X-Forwarded-For-header die is ingesteld door Application Gateway opnieuw wilt schrijven, zodat de header alleen het IP-adres zonder poortgegevens bevat. |
| ciphers_supported | Een lijst met de coderingen die door de client worden ondersteund. |
| ciphers_used | De tekenreeks met coderingen die worden gebruikt voor een tot stand gebrachte TLS-verbinding. |
| client_ip | Het IP-adres van de client van waaruit de toepassingsgateway de aanvraag heeft ontvangen. Als er een omgekeerde proxy is vóór de toepassingsgateway en de oorspronkelijke client, client_ip retourneert u het IP-adres van de omgekeerde proxy. |
| client_port | De clientpoort. |
| client_tcp_rtt | Informatie over de TCP-clientverbinding. Beschikbaar op systemen die ondersteuning bieden voor de TCP_INFO socketoptie. |
| client_user | Wanneer HTTP-verificatie wordt gebruikt, wordt de gebruikersnaam opgegeven voor verificatie. |
| host | In deze volgorde van prioriteit: de hostnaam van de aanvraagregel, de hostnaam uit het veld Hostaanvraagheader of de servernaam die overeenkomt met een aanvraag. Voorbeeld: In de aanvraag http://contoso.com:8080/article.aspx?id=123&title=fabrikamis de hostwaarde contoso.com |
| cookie_naam | De naam cookie. |
| http_method | De methode die wordt gebruikt om de URL-aanvraag te doen. Bijvoorbeeld GET of POST. |
| http_status | De sessiestatus. Bijvoorbeeld 200, 400 of 403. |
| http_version | Het aanvraagprotocol. Meestal HTTP/1.0, HTTP/1.1 of HTTP/2.0. |
| query_string | De lijst met variabele/waardeparen die de '?' volgen in de aangevraagde URL. Voorbeeld: In de aanvraag http://contoso.com:8080/article.aspx?id=123&title=fabrikamis query_string waarde id=123&title=fabrikam |
| received_bytes | De lengte van de aanvraag (inclusief de aanvraagregel, header en aanvraagbody). |
| request_query | De argumenten in de aanvraagregel. |
| request_scheme | Het aanvraagschema: http of https. |
| request_uri | De volledige oorspronkelijke aanvraag-URI (met argumenten). Voorbeeld: in de aanvraag http://contoso.com:8080/article.aspx?id=123&title=fabrikam*is request_uri waarde /article.aspx?id=123&title=fabrikam |
| sent_bytes | Het aantal bytes dat naar een client is verzonden. |
| server_port | De poort van de server die een aanvraag heeft geaccepteerd. |
| ssl_connection_protocol | Het protocol van een tot stand gebrachte TLS-verbinding. |
| ssl_enabled | 'Aan' als de verbinding werkt in de TLS-modus. Anders is er een lege tekenreeks. |
| uri_path | Identificeert de specifieke resource in de host waartoe de webclient toegang wil hebben. De variabele verwijst naar het oorspronkelijke URL-pad, vóór elke manipulatie. Dit is het deel van de aanvraag-URI zonder de argumenten. In de aanvraag http://contoso.com:8080/article.aspx?id=123&title=fabrikamis /article.aspxde uri_path waarde bijvoorbeeld . |
Servervariabelen voor wederzijdse verificatie
Application Gateway ondersteunt de volgende servervariabelen voor wederzijdse verificatiescenario's. Gebruik deze servervariabelen op dezelfde manier als hierboven met de andere servervariabelen.
| Variabelenaam | Beschrijving |
|---|---|
| client_certificate | Het clientcertificaat in PEM-indeling voor een tot stand gebrachte SSL-verbinding. |
| client_certificate_end_date | De einddatum van het clientcertificaat. |
| client_certificate_fingerprint | De SHA1-vingerafdruk van het clientcertificaat voor een tot stand gebrachte SSL-verbinding. |
| client_certificate_issuer | De tekenreeks 'issuer DN' van het clientcertificaat voor een tot stand gebrachte SSL-verbinding. |
| client_certificate_serial | Het serienummer van het clientcertificaat voor een tot stand gebrachte SSL-verbinding. |
| client_certificate_start_date | De begindatum van het clientcertificaat. |
| client_certificate_subject | De tekenreeks 'onderwerp-DN' van het clientcertificaat voor een tot stand gebrachte SSL-verbinding. |
| client_certificate_verification | Het resultaat van de verificatie van het clientcertificaat: GESLAAGD, MISLUKT:<reden> of GEEN als er geen certificaat aanwezig was. |
Algemene scenario's voor het herschrijven van headers
Poortgegevens verwijderen uit de header X-Forwarded-For
Application Gateway voegt een X-Forwarded-For-header in alle aanvragen in voordat deze de aanvragen doorstuurt naar de back-end. Deze header is een door komma's gescheiden lijst met IP-poorten. Er kunnen scenario's zijn waarin de back-endservers alleen de headers nodig hebben om IP-adressen te bevatten. U kunt het herschrijven van headers gebruiken om de poortgegevens uit de X-Forwarded-For-header te verwijderen. Een manier om dit te doen, is door de header in te stellen op de add_x_forwarded_for_proxy servervariabele. U kunt ook de variabele client_ip gebruiken:
Een omleidings-URL wijzigen
Het wijzigen van een omleidings-URL kan onder bepaalde omstandigheden nuttig zijn. Bijvoorbeeld: clients zijn oorspronkelijk omgeleid naar een pad zoals '/blog', maar nu moeten worden verzonden naar '/updates' vanwege een wijziging in de inhoudsstructuur.
Waarschuwing
De noodzaak om een omleidings-URL te wijzigen, komt soms voor in de context van een configuratie waarbij Application Gateway is geconfigureerd om de hostnaam naar de back-end te overschrijven. De hostnaam die door de back-end wordt gezien, verschilt in dat geval van de hostnaam, zoals wordt gezien door de browser. In dit geval gebruikt de omleiding niet de juiste hostnaam. Deze configuratie wordt niet aanbevolen.
De beperkingen en gevolgen van een dergelijke configuratie worden beschreven in Behoud de oorspronkelijke HTTP-hostnaam tussen een omgekeerde proxy en de back-endwebtoepassing. De aanbevolen installatie voor App Service is om de instructies voor 'Aangepast domein (aanbevolen)' te volgen in App Service configureren met Application Gateway. Het herschrijven van de locatieheader in het antwoord, zoals beschreven in het onderstaande voorbeeld, moet als tijdelijke oplossing worden beschouwd en de hoofdoorzaak niet aanpakken.
Wanneer de App Service een omleidingsantwoord verzendt, gebruikt deze dezelfde hostnaam in de locatieheader van het antwoord als de hostnaam in de aanvraag die wordt ontvangen van de toepassingsgateway. De client doet de aanvraag dus rechtstreeks naar contoso.azurewebsites.net/path2 in plaats van via de toepassingsgateway (contoso.com/path2). Het omzeilen van de toepassingsgateway is niet wenselijk.
U kunt dit probleem oplossen door de hostnaam in de locatieheader in te stellen op de domeinnaam van de toepassingsgateway.
Hier volgen de stappen voor het vervangen van de hostnaam:
Maak een herschrijfregel met een voorwaarde die evalueert of de locatieheader in het antwoord azurewebsites.net bevat. Voer het patroon in
(https?):\/\/.*azurewebsites\.net(.*)$.Voer een actie uit om de locatieheader opnieuw te schrijven, zodat deze de hostnaam van de toepassingsgateway heeft. Voer dit in door de headerwaarde in te voeren
{http_resp_Location_1}://contoso.com{http_resp_Location_2}. U kunt ook de servervariabelehostgebruiken om de hostnaam in te stellen op basis van de oorspronkelijke aanvraag.
HTTP-headers voor beveiliging implementeren om beveiligingsproblemen te voorkomen
U kunt verschillende beveiligingsproblemen oplossen door de benodigde headers in het toepassingsantwoord te implementeren. Deze beveiligingsheaders omvatten X-XSS-Protection, Strict-Transport-Security en Content-Security-Policy. U kunt Application Gateway gebruiken om deze headers in te stellen voor alle antwoorden.
Ongewenste headers verwijderen
Mogelijk wilt u headers verwijderen die gevoelige informatie uit een HTTP-antwoord onthullen. U kunt bijvoorbeeld informatie verwijderen, zoals de naam van de back-endserver, het besturingssysteem of bibliotheekgegevens. U kunt de toepassingsgateway gebruiken om deze headers te verwijderen:
Het is niet mogelijk om een herschrijfregel te maken om de hostheader te verwijderen. Als u probeert een herschrijfregel te maken met het actietype dat is ingesteld om te verwijderen en de header is ingesteld op host, resulteert dit in een fout.
Controleren op de aanwezigheid van een koptekst
U kunt een HTTP-aanvraag of antwoordheader evalueren voor de aanwezigheid van een header of servervariabele. Deze evaluatie is handig als u een koptekst alleen opnieuw wilt schrijven wanneer een bepaalde koptekst aanwezig is.
Veelvoorkomende scenario's voor het herschrijven van URL's
Selectie van pad op basis van parameters
Als u scenario's wilt uitvoeren waarin u de back-endpool wilt kiezen op basis van de waarde van een header, een deel van de URL of queryreeks in de aanvraag, kunt u een combinatie van url-herschrijfmogelijkheden en padgebaseerde routering gebruiken.
Hiervoor maakt u een herschrijfset met een voorwaarde die controleert op een specifieke parameter (querytekenreeks, header, enzovoort) en voert u vervolgens een actie uit waarin het URL-pad wordt gewijzigd (zorg ervoor dat padtoewijzing opnieuw wordt geëvalueerd). De herschrijfset moet vervolgens worden gekoppeld aan een regel op basis van een pad. De padgebaseerde regel moet dezelfde URL-paden bevatten die zijn opgegeven in de herschrijfset en de bijbehorende back-endpool.
Met de herschrijfset kunnen gebruikers dus controleren op een specifieke parameter en deze toewijzen aan een nieuw pad. Met de regel op basis van het pad kunnen gebruikers back-endpools aan deze paden toewijzen. Zolang 'Padtoewijzing opnieuw geëvalueerd' is ingeschakeld, wordt verkeer gerouteerd op basis van het pad dat is opgegeven in de herschrijfset.
Zie Verkeer routeren met behulp van op parameters gebaseerde padselectie in de portal voor een voorbeeld van een use-case met behulp van queryreeksen.
Queryreeksparameters herschrijven op basis van de URL
Overweeg een scenario van een winkelwebsite waarbij de zichtbare koppeling van de gebruiker eenvoudig en leesbaar moet zijn, maar de back-endserver de queryreeksparameters nodig heeft om de juiste inhoud weer te geven.
In dat geval kan Application Gateway parameters uit de URL vastleggen en sleutel-waardeparen voor queryreeksen toevoegen uit de sleutel-waardeparen uit de URL. Stel dat de gebruiker wil herschrijven, https://www.contoso.com/fashion/shirts zodat https://www.contoso.com/buy.aspx?category=fashion&product=shirtshet kan worden bereikt via de volgende configuratie voor het herschrijven van url's.
Voorwaarde : als de servervariabele uri_path gelijk is aan het patroon /(.+)/(.+)
Actie : URL-pad instellen op buy.aspx en queryreeks instellen op category={var_uri_path_1}&product={var_uri_path_2}
Zie De URL herschrijven met Application Gateway met behulp van Azure Portal voor een stapsgewijze handleiding voor het bereiken van het hierboven beschreven scenario
Algemene valkuilen voor configuratie herschrijven
Het inschakelen van padtoewijzing voor opnieuw uitvoeren is niet toegestaan voor basisregels voor aanvraagroutering. Dit is om oneindige evaluatielus voor een basisrouteringsregel te voorkomen.
Er moet ten minste één regel voor voorwaardelijk herschrijven of 1 herschrijfregel zijn waarvoor 'Padtoewijzing opnieuw evalueren' niet is ingeschakeld voor padgebaseerde routeringsregels om oneindige evaluatielus voor een padgebaseerde routeringsregel te voorkomen.
Binnenkomende aanvragen worden beëindigd met een 500-foutcode voor het geval een lus dynamisch wordt gemaakt op basis van clientinvoer. Application Gateway blijft andere aanvragen verwerken zonder dat er in een dergelijk scenario sprake is van een verslechtering.
URL opnieuw schrijven of hostheader herschrijven met Web Application Firewall (WAF_v2 SKU)
Wanneer u het herschrijven van url's of het herschrijven van hostheaders configureert, vindt de WAF-evaluatie plaats na de wijziging van de aanvraagheader- of URL-parameters (na herschrijven). En wanneer u de configuratie voor het herschrijven van url's of hostheaders op uw Application Gateway verwijdert, wordt de WAF-evaluatie uitgevoerd voordat de header opnieuw wordt geschreven (vooraf herschrijven). Deze volgorde zorgt ervoor dat WAF-regels worden toegepast op de uiteindelijke aanvraag die wordt ontvangen door uw back-endpool.
Stel dat u de volgende regel voor het herschrijven van headers voor de header "Accept" : "text/html" hebt: als de waarde van de header "Accept" gelijk is aan "text/html", herschrijft u de waarde vervolgens naar "image/png".
Hier, met alleen herschrijven van headers geconfigureerd, wordt de WAF-evaluatie uitgevoerd op "Accept" : "text/html". Maar wanneer u het herschrijven van url's of het herschrijven van hostheaders configureert, wordt de WAF-evaluatie uitgevoerd op "Accept" : "image/png".
URL herschrijven versus URL-omleiding
Voor het herschrijven van een URL herschrijft Application Gateway de URL voordat de aanvraag naar de back-end wordt verzonden. Hierdoor wordt niet gewijzigd wat gebruikers in de browser zien, omdat de wijzigingen verborgen zijn voor de gebruiker.
Voor een URL-omleiding verzendt Application Gateway een omleidingsreactie naar de client met de nieuwe URL. Op zijn beurt moet de client de aanvraag opnieuw verzenden naar de nieuwe URL die is opgegeven in de omleiding. De URL die de gebruiker in de browser ziet, wordt bijgewerkt naar de nieuwe URL.
Beperkingen
- Herschrijven wordt niet ondersteund wanneer de toepassingsgateway is geconfigureerd om de aanvragen om te leiden of om een aangepaste foutpagina weer te geven.
- Namen van aanvraagheaders kunnen alfanumerieke tekens en afbreekstreepjes bevatten. Koptekstnamen met andere tekens worden verwijderd wanneer een aanvraag naar het back-enddoel wordt verzonden.
- Namen van antwoordheaders kunnen alfanumerieke tekens en specifieke symbolen bevatten, zoals gedefinieerd in RFC 7230.
- Verbindings- en upgradeheaders kunnen niet opnieuw worden geschreven
- Herschrijven wordt niet ondersteund voor 4xx- en 5xx-antwoorden die rechtstreeks vanuit Application Gateway worden gegenereerd