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.

Notitie

Http-header- en URL-herschrijffuncties zijn alleen beschikbaar voor de Application Gateway v2-SKU

Ondersteunde typen herschrijven

Aanvraag- en antwoordheaders

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.

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.

Zie hier voor meer informatie over het herschrijven van aanvraag- en antwoordheaders met Application Gateway met behulp van Azure Portal.

Ondersteunde headers

U kunt alle headers in aanvragen en antwoorden herschrijven, met uitzondering van de Verbinding maken ion en upgradeheaders. U kunt de toepassingsgateway ook gebruiken om aangepaste headers te maken en deze toe te voegen aan de aanvragen en antwoorden die worden gerouteerd.

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.

Acties herschrijven

U gebruikt herschrijfacties om de URL, aanvraagheaders of antwoordheaders op te geven die u wilt herschrijven en de nieuwe waarde waarnaar u ze wilt herschrijven. De waarde van een URL of een nieuwe of bestaande header kan worden ingesteld op deze typen waarden:

• Sms verzenden
• Aanvraagheader. Als u een aanvraagheader wilt opgeven, moet u de syntaxis {http_req_headerName} gebruiken
• Antwoordheader. Als u een antwoordheader wilt opgeven, moet u de syntaxis {http_resp_headerName} gebruiken
• Servervariabele. Als u een servervariabele wilt opgeven, moet u de syntaxis {var_serverVariable} gebruiken. Bekijk de lijst met ondersteunde servervariabelen
• Een combinatie van tekst, een aanvraagheader, een antwoordheader en een servervariabele.

Voorwaarden herschrijven

U kunt herschrijfvoorwaarden, een optionele configuratie, gebruiken om de inhoud van HTTP(S)-aanvragen en -antwoorden te evalueren en alleen een herschrijfbewerking uit te voeren wanneer aan een of meer voorwaarden wordt voldaan. De toepassingsgateway gebruikt deze typen variabelen om de inhoud van aanvragen en antwoorden te evalueren:

• HTTP-headers in de aanvraag
• HTTP-headers in het antwoord
• Application Gateway-servervariabelen

U kunt een voorwaarde gebruiken om te evalueren of een opgegeven variabele aanwezig is, of een opgegeven variabele overeenkomt met een specifieke waarde of of een opgegeven variabele overeenkomt met een specifiek patroon.

Patroonherkenning

Application Gateway maakt gebruik van reguliere expressies voor patroonkoppeling in de voorwaarde. U moet regulier expressies (RE2) gebruiken bij het schrijven van uw voorwaarden. 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).

Vastleggen

Als u een subtekenreeks wilt vastleggen voor later gebruik, plaatst u haakjes rond het subpatroon dat overeenkomt met de subtekenreeks in de regex-definitie van de voorwaarde. 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. Enkele voorbeelden van verw:

• (\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

Notitie

Het gebruik van / voorvoegsel en achtervoegsel mag niet worden opgegeven in het patroon om de waarde te vinden. (\d)(\d) komt bijvoorbeeld overeen met twee cijfers. /(\d)(\d)/ komt niet overeen met twee cijfers.

Nadat u deze hebt vastgelegd, kunt u ernaar verwijzen in 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}
• Voor een servervariabele moet u {var_serverVariableName_groupNumber} gebruiken. Bijvoorbeeld {var_uri_path_1} of {var_uri_path_2}

Notitie

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	Omschrijving
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 met name handig wanneer u de X-Forwarded-For-header die is ingesteld door Application Gateway opnieuw wilt schrijven, zodat de header alleen het IP-adres bevat zonder de poortgegevens.
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. Dit is het deel van de aanvraag-URI zonder de argumenten. Voorbeeld: In de aanvraag http://contoso.com:8080/article.aspx?id=123&title=fabrikamis uri_path waarde /article.aspx

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	Omschrijving
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.

Configuratie herschrijven

Als u een herschrijfregel wilt configureren, moet u een herschrijfregelset maken en daarin de herschrijfregelconfiguratie toevoegen.

Een regelset voor herschrijven bevat:

• Koppeling van routeringsregel aanvragen: de herschrijfconfiguratie is gekoppeld aan de bronlistener via de routeringsregel. Wanneer u een basisrouteringsregel gebruikt, wordt de herschrijfconfiguratie gekoppeld aan een bronlistener en is het herschrijven van een algemene header. Wanneer u een padgebaseerde routeringsregel gebruikt, wordt de herschrijfconfiguratie gedefinieerd op de URL-padtoewijzing. In dat geval geldt dit alleen voor het specifieke padgebied van een site. U kunt meerdere herschrijfsets maken en elke herschrijfset toepassen op meerdere listeners. Maar u kunt slechts één herschrijfprogramma toepassen op een specifieke listener.

• Herschrijfvoorwaarde: het is een optionele configuratie. Herschrijfvoorwaarden evalueren de inhoud van de HTTP(S)-aanvragen en -antwoorden. De herschrijfactie vindt plaats als de HTTP(S)-aanvraag of -reactie overeenkomt met de herschrijfvoorwaarde. Als u meer dan één voorwaarde aan een actie koppelt, treedt de actie alleen op wanneer aan alle voorwaarden wordt voldaan. Met andere woorden, de bewerking is een logische AND-bewerking.

• Herschrijftype: Er zijn drie typen herschrijven beschikbaar:

  • Aanvraagheaders herschrijven
  • Antwoordheaders herschrijven
  • URL-onderdelen herschrijven
    • URL-pad: de waarde waarnaar het pad moet worden herschreven.
    • URL-queryreeks: de waarde waarnaar de querytekenreeks moet worden herschreven.
    • Padtoewijzing opnieuw evalueren: wordt gebruikt om te bepalen of de URL-padtoewijzing moet worden geëvalueerd of niet. 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.

Algemene valkuilen voor configuratie herschrijven

• Het inschakelen van padtoewijzing voor opnieuw evalueren is niet toegestaan voor basisregels voor het doorsturen van aanvragen. 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. De Application Gateway blijft andere aanvragen verwerken zonder dat er sprake is van een verslechtering in een dergelijk scenario.

URL opnieuw schrijven of hostheader herschrijven met Web Application Firewall (WAF_v2 SKU)

Wanneer u het herschrijven van url's of het herschrijven van de hostheader 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, waarbij alleen het herschrijven van headers is geconfigureerd, wordt de WAF-evaluatie uitgevoerd op "Accept" : "text/html". Maar wanneer u het herschrijven van url's of het herschrijven van de hostheader configureert, wordt de WAF-evaluatie uitgevoerd op "Accept" : "image/png".

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:

1. Maak een herschrijfregel met een voorwaarde die evalueert of de locatieheader in het antwoord azurewebsites.net bevat. Voer het patroon in (https?):\/\/.*azurewebsites\.net(.*)$.
2. 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 servervariabele host gebruiken 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:

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 waarbij u de back-endpool wilt kiezen op basis van de waarde van een header, een deel van de URL of een queryreeks in de aanvraag, kunt u de combinatie van url-herschrijfmogelijkheden en padgebaseerde routering gebruiken. Als u bijvoorbeeld een winkelwebsite hebt en de productcategorie wordt doorgegeven als querytekenreeks in de URL en u de aanvraag wilt routeren naar de back-end op basis van de querytekenreeks, dan:

Stap 1: Maak een padoverzicht zoals wordt weergegeven in de onderstaande afbeelding

Stap 2 (a): Maak een herschrijfset met drie herschrijfregels:

• De eerste regel heeft een voorwaarde die de query_string variabele controleert op category=schoenen en een actie heeft waarmee het URL-pad naar /listing1 wordt herschreven en padtoewijzing opnieuw evalueren is ingeschakeld

• De tweede regel heeft een voorwaarde die de query_string variabele controleert op category=bags en een actie heeft waarmee het URL-pad naar /listing2 wordt herschreven en padtoewijzing opnieuw evalueren is ingeschakeld

• De derde regel heeft een voorwaarde die de query_string variabele controleert op category=accessories en een actie heeft waarmee het URL-pad wordt herschreven naar /listing3 en padtoewijzing opnieuw evalueren is ingeschakeld

Stap 2 (b): Koppel deze herschrijfset aan het standaardpad van de bovenstaande padgebaseerde regel

Als de gebruiker nu contoso.com/listing?category=any aanvraagt, wordt deze gekoppeld aan het standaardpad, omdat geen van de padpatronen in de padkaart (/listing1, /listing2, /listing3) overeenkomt. Omdat u de bovenstaande herschrijfset aan dit pad hebt gekoppeld, wordt deze herschrijfset geëvalueerd. Omdat de querytekenreeks niet overeenkomt met de voorwaarde in een van de drie herschrijfregels in deze herschrijfset, vindt er geen herschrijfactie plaats en wordt de aanvraag daarom ongewijzigd gerouteerd naar de back-end die is gekoppeld aan het standaardpad (dit is GenericList).

Als de gebruiker contoso.com/listing?category=shoes aanvraagt, wordt het standaardpad opnieuw vergeleken. In dit geval komt de voorwaarde in de eerste regel echter overeen en daarom wordt de actie die aan de voorwaarde is gekoppeld, uitgevoerd, waarmee het URL-pad naar /listing1 wordt herschreven en de padtoewijzing opnieuw wordt geëvalueerd. Wanneer de padtoewijzing opnieuw wordt geëvalueerd, komt de aanvraag nu overeen met het pad dat is gekoppeld aan patroon /listing1 en wordt de aanvraag doorgestuurd naar de back-end die aan dit patroon is gekoppeld. Dit is ShoesListBackendPool.

Notitie

Dit scenario kan worden uitgebreid naar elke header- of cookiewaarde, URL-pad, querytekenreeks of servervariabelen op basis van de gedefinieerde voorwaarden en stelt u in feite in staat aanvragen te routeren op basis van deze voorwaarden.

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

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

• Als een antwoord meer dan één koptekst met dezelfde naam heeft, leidt het herschrijven van de waarde van een van deze headers ertoe dat de andere headers in het antwoord worden verwijderd. Dit kan meestal gebeuren met set-cookieheader, omdat u meer dan één Set-Cookie-header in een antwoord kunt hebben. Een dergelijk scenario is wanneer u een app-service gebruikt met een toepassingsgateway en sessieaffiniteit op basis van cookies op de toepassingsgateway hebt geconfigureerd. In dit geval bevat het antwoord twee set-cookieheaders: een header die wordt gebruikt door de app-service, bijvoorbeeld: Set-Cookie: ARRAffinity=ba127f1caf6ac822b2347cc18bba0364d699ca1ad44d20e0ec01ea80cda2a735;Path=/;HttpOnly;Domain=sitename.azurewebsites.net en een andere voor toepassingsgatewayaffiniteit, bijvoorbeeld Set-Cookie: ApplicationGatewayAffinity=c1a2bd51lfd396387f96bl9cc3d2c516; Path=/. Het herschrijven van een van de Set-Cookie-headers in dit scenario kan ertoe leiden dat de andere Set-Cookie-header uit het antwoord wordt verwijderd.
• 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.
• Verbinding maken ion- en upgradeheaders kunnen niet opnieuw worden geschreven
• Herschrijven wordt niet ondersteund voor 4xx- en 5xx-antwoorden die rechtstreeks vanuit Application Gateway worden gegenereerd

Volgende stappen

• Meer informatie over het herschrijven van HTTP-headers met Application Gateway met behulp van Azure Portal
• Meer informatie over het herschrijven van URL's met Application Gateway met behulp van Azure Portal