HTTP-headers en -URL opnieuw schrijven met Application Gateway

Application Gateway kunt u geselecteerde inhoud van aanvragen en antwoorden herschrijven. Met deze functie kunt u URL's, queryreeksparameters en aanvraag- en antwoordheaders wijzigen. U kunt er ook voorwaarden aan toevoegen om ervoor te zorgen dat de URL of de opgegeven headers alleen opnieuw worden geschreven wanneer aan bepaalde voorwaarden wordt voldaan. Deze voorwaarden zijn gebaseerd op de informatie in de aanvraag en het antwoord.

Ondersteunde typen herschrijven

Aanvraag- en reactieheaders

Met HTTP-headers kunnen 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 headervelden zoals HSTS/X-XSS-Protection, het verwijderen van antwoordheadervelden die gevoelige informatie kunnen weergeven en het verwijderen van poortgegevens uit X-Forwarded-For-headers.

In Application Gateway kunt u headers van HTTP-aanvragen en -antwoorden toevoegen, verwijderen of bijwerken terwijl aanvraag- en antwoordpakketten zich verplaatsen tussen de client en back-endpools.

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

Ondersteunde headers

U kunt alle headers in aanvragen en antwoorden opnieuw schrijven, met uitzondering van de verbindings- en upgradeheaders. U kunt de toepassingsgateway ook gebruiken om aangepaste headers te maken en deze toe te voegen aan de aanvragen en antwoorden die erdoor worden doorgeleid.

URL-pad en queryreeks

Met de mogelijkheid om URL's te herschrijven in Application Gateway, kunt u het volgende doen:

• De hostnaam, het pad en de queryreeks van de aanvraag-URL opnieuw schrijven

• Kies ervoor om de URL van alle aanvragen op een listener te herschrijven of alleen de aanvragen die overeenkomen met een of meer van de voorwaarden die u hebt ingesteld. Deze voorwaarden zijn gebaseerd op de aanvraag- en antwoordeigenschappen (aanvraag-, header-, antwoordheader- en servervariabelen).

• Kies ervoor om de aanvraag te sturen (selecteer de back-endpool) op basis van de oorspronkelijke URL of de herschreven URL

Zie hier voor meer informatie over het herschrijven van url'Application Gateway met Azure Portal.

Acties herschrijven

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

• Tekst
• 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}. Zie de lijst met ondersteunde servervariabelen
• Een combinatie van tekst, een aanvraagheader, een antwoordheader en een servervariabele.

Voorwaarden herschrijven

U kunt voorwaarden voor herschrijven, een optionele configuratie, gebruiken om de inhoud van HTTP(S)-aanvragen en -antwoorden te evalueren en alleen een herschrijven 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 dat een opgegeven variabele overeenkomt met een specifiek patroon.

Patroonherkenning

Application Gateway maakt gebruik van reguliere expressies voor patroonmatching in de voorwaarde. U kunt de PCRE-bibliotheek (Perl Compatible Regular Expressions) gebruiken om een patroon voor reguliere expressies in te stellen dat overeenkomt met de voorwaarden. Zie de hoofdpagina voor Reguliere expressies perl voor meer informatie over de syntaxis van reguliere expressies.

Vastleggen

Als u een subtekenreeks wilt vastleggen voor later gebruik, zet u haakjes rond het subpatroon dat overeenkomt met de subtekenreeks in de regex-voorwaardedefinitie. Het eerste paar haakjes slaat de subtekenreeks op in 1, het tweede paar in 2, en meer. U kunt zoveel haakjes gebruiken als u wilt; Perl blijft alleen maar meer genummerde variabelen definiëren om deze vastgelegde tekenreeksen weer te geven. Enkele voorbeelden van ref:

• /(\d)(\d)/ # Overeenkomen met twee cijfers, en deze vastleggen in de groepen 1 en 2

• /(\d+)/ # Overeenkomen met een of meer cijfers, en deze allemaal vastleggen in groep 1

• /(\d)+/ # Komen een of meer keer overeen met een cijfer, en leggen de laatste vast in groep 1

Na het maken kunt u er in de actieset naar verwijzen met behulp van de volgende indeling:

• Voor het vastleggen van een aanvraagheader moet u {http_req_headerName_groupNumber}. Bijvoorbeeld {http_req_User-Agent_1} of {http_req_User-Agent_2}
• Voor het vastleggen van een antwoordheader moet u {http_resp_headerName_groupNumber}. Bijvoorbeeld {http_resp_Location_1} of {http_resp_Location_2}
• Voor een servervariabele moet u {var_serverVariableName_groupNumber}. Bijvoorbeeld {var_uri_path_1} of {var_uri_path_2}

Als u de hele waarde wilt gebruiken, moet u het getal niet noemen. Gebruik gewoon de notatie {http_req_headerName}, enzovoort, zonder het groupNumber.

Servervariabelen

Application Gateway gebruikt servervariabelen voor het opslaan van nuttige informatie over de server, de verbinding met de client en de huidige aanvraag voor de verbinding. Voorbeelden van informatie die is opgeslagen, zijn het IP-adres van de client en het type webbrowser. Servervariabelen veranderen dynamisch, bijvoorbeeld wanneer een nieuwe pagina wordt geladen of wanneer een formulier wordt geplaatst. U kunt deze variabelen gebruiken om herschrijfvoorwaarden te evalueren en headers opnieuw te schrijven. 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:

Servervariabelen voor wederzijdse verificatie (preview)

Application Gateway ondersteunt de volgende servervariabelen voor wederzijdse verificatiescenario's. Gebruik deze servervariabelen op dezelfde manier als hierboven met de andere servervariabelen.

Configuratie herschrijven

Als u een herschrijfregel wilt configureren, moet u een regelset voor herschrijven maken en de herschrijfregelconfiguratie toevoegen.

Een regelset voor herschrijven bevat:

• Routeringsregelkoppeling aanvragen: De herschrijfconfiguratie is via de routeringsregel gekoppeld aan de bronlistener. Wanneer u een basisregel voor doorsturen gebruikt, wordt de herschrijfconfiguratie gekoppeld aan een bronlistener en is het herschrijven van globale headers. Wanneer u een padgebaseerde routeringsregel gebruikt, wordt de herschrijfconfiguratie gedefinieerd op de URL-padkaart. 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 herschrijfset toepassen op een specifieke listener.

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

• Type herschrijven: er zijn drie typen herschrijftypen beschikbaar:

  • Aanvraagheaders herschrijven
  • Antwoordheaders herschrijven
  • URL-onderdelen herschrijven
    • URL-pad: de waarde waar het pad naar moet worden herschreven.
    • URL-queryreeks: de waarde waarin de queryreeks moet worden herschreven.
    • Padkaart opnieuw evalueren: wordt gebruikt om te bepalen of de URL-padkaart al dan niet opnieuw moet worden geëvalueerd. Als dit niet wordt aangevinkt, wordt het oorspronkelijke URL-pad gebruikt om overeen te komen met het padpatroon in de URL-padkaart. Als deze is ingesteld op true, wordt de URL-padkaart 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 het herschrijven.

Veelvoorkomende valkuilen bij het herschrijven van configuraties

• Het inschakelen van Padkaart opnieuw evalueren is niet toegestaan voor basisregels voor doorsturen van aanvragen. Dit is om een oneindige evaluatielus voor een basisrouteringsregel te voorkomen.

• Er moet ten minste één regel voor voorwaardelijk herschrijven of één herschrijfregel zijn waarvoor padkaart opnieuw evalueren niet is ingeschakeld voor padgebaseerde routeringsregels om een oneindige evaluatielus voor een padgebaseerde routeringsregel te voorkomen.

• Binnenkomende aanvragen worden beëindigd met een 500-foutcode voor het geval er dynamisch een lus wordt gemaakt op basis van clientinvoer. De Application Gateway blijven andere aanvragen verwerken zonder dat dit in een dergelijk scenario afloakt.

URL's herschrijven 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 het herschrijven). En wanneer u de configuratie voor het herschrijven van de URL of het herschrijven van de hostheader op uw Application Gateway verwijdert, wordt de WAF-evaluatie uitgevoerd vóór het herschrijven van de header (vooraf herschrijven). Deze volgorde zorgt ervoor dat WAF-regels worden toegepast op de laatste aanvraag die wordt ontvangen door uw back-endpool.

Stel dat u de volgende regel voor het herschrijven van headers hebt voor de header . Als de waarde van header gelijk is aan , herschrijft u de "Accept" : "text/html" "Accept" waarde vervolgens naar "text/html" "image/png" .

Nu alleen 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" .

Veelvoorkomende scenario's voor het herschrijven van headers

Poortgegevens verwijderen uit de X-Forwarded-For-header

Application Gateway een X-Forwarded-For-header in alle aanvragen in voordat de aanvragen naar de back-end worden doorgestuurd. Deze header is een door komma's gescheiden lijst met IP-poorten. Er zijn mogelijk scenario's waarin de back-endservers alleen de headers nodig hebben om IP-adressen te bevatten. U kunt header herschrijven gebruiken om de poortgegevens uit de X-Forwarded-For-header te verwijderen. U kunt dit onder andere doen door de header in te stellen op de add_x_forwarded_for_proxy servervariabele. U kunt ook de variabele client_ip:

Een omleidings-URL wijzigen

Wanneer een back-endtoepassing een omleidingsreactie verzendt, wilt u de client mogelijk omleiden naar een andere URL dan de URL die is opgegeven door de back-endtoepassing. U kunt dit bijvoorbeeld doen wanneer een app-service wordt gehost achter een toepassingsgateway en de client een omleiding naar het relatieve pad moet doen. (Bijvoorbeeld een omleiding van contoso.azurewebsites.net/path1 naar contoso.azurewebsites.net/path2.)

Omdat App Service een multitenant-service is, wordt de hostheader in de aanvraag gebruikt om de aanvraag naar het juiste eindpunt te sturen. App Services hebben een standaarddomeinnaam van .azurewebsites.net (bijvoorbeeld contoso.azurewebsites.net) die verschilt van de domeinnaam van de toepassingsgateway * (bijvoorbeeld contoso.com). Omdat de oorspronkelijke aanvraag van de client de domeinnaam (contoso.com) van de toepassingsgateway als hostnaam heeft, wijzigt de toepassingsgateway de hostnaam in contoso.azurewebsites.net. Deze wijziging wordt zo gewijzigd dat de app-service de aanvraag kan door sturen naar het juiste eindpunt.

Wanneer de app-service een omleidingsreactie verzendt, gebruikt deze dezelfde hostnaam in de locatieheader van het antwoord als in de aanvraag die wordt ontvangen van de toepassingsgateway. De client maakt de aanvraag dus rechtstreeks naar in contoso.azurewebsites.net/path2 plaats van via de toepassingsgateway ( contoso.com/path2 ). Het is niet wenselijk om de toepassingsgateway over te nemen.

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. Voer het patroon (https?):\/\/.*azurewebsites\.net(.*)$ in.
2. Voer een actie uit om de locatieheader te herschrijven, zodat deze de hostnaam van de toepassingsgateway heeft. Dit doet u door in te {http_resp_Location_1}://contoso.com{http_resp_Location_2} invoeren als de headerwaarde. U kunt ook de servervariabele gebruiken om de hostnaam in host te stellen op de oorspronkelijke aanvraag.

HTTP-headers voor beveiliging implementeren om beveiligingsproblemen te voorkomen

U kunt verschillende beveiligingsproblemen oplossen door de benodigde headers in het antwoord van de toepassing te implementeren. Deze beveiligingsheaders omvatten X-XSS-Protection, Strict-Transport-Security en Content-Security-Policy. U kunt Application Gateway om deze headers in te stellen voor alle antwoorden.

Ongewenste headers verwijderen

Mogelijk wilt u headers verwijderen die gevoelige informatie uit een HTTP-antwoord weergeven. U wilt bijvoorbeeld informatie zoals de naam van de back-endserver, het besturingssysteem of de bibliotheekgegevens verwijderen. U kunt de toepassingsgateway gebruiken om deze headers te verwijderen:

Controleren op de aanwezigheid van een header

U kunt een HTTP-aanvraag of antwoordheader evalueren op de aanwezigheid van een header- of servervariabele. Deze evaluatie is handig als u een header alleen wilt herschrijven wanneer een bepaalde header aanwezig is.

Algemene scenario's voor het herschrijven van URL's

Padselectie 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 querytekenreeks in de aanvraag, kunt u de combinatie van mogelijkheid voor het herschrijven van URL's 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 door sturen naar de back-end op basis van de querytekenreeks, doet u het volgende:

Stap 1: Maak een padkaart 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=shoes en een actie heeft waarmee het URL-pad naar /listing1 wordt herschreven en padkaart opnieuw evalueren is ingeschakeld

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

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

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

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

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

Queryreeksparameters herschrijven op basis van de URL

Denk aan een scenario van een winkelwebsite waarbij de koppeling met de zichtbare gebruiker eenvoudig en leesbaar moet zijn, maar de back-endserver de queryreeksparameters nodig heeft om de juiste inhoud weer te geven.

In dat geval kunnen Application Gateway parameters uit de URL vastleggen en sleutel-waardeparen van queryreeksen uit de URL toevoegen. Stel bijvoorbeeld dat de gebruiker wil herschrijven naar , dit kan worden bereikt via de volgende configuratie voor https://www.contoso.com/fashion/shirts https://www.contoso.com/buy.aspx?category=fashion&product=shirts 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 op category={var_uri_path_1}&product={var_uri_path_2}

Zie URL herschrijven met een Application Gateway met behulp van Azure Portal voor een stapsgewijs scenario dat hierboven wordt beschreven Azure Portal

URL herschrijven versus URL-omleiding

In het geval van het herschrijven van een URL herschrijft Application Gateway URL opnieuw voordat de aanvraag naar de back-end wordt verzonden. Dit verandert niet wat gebruikers in de browser zien, omdat de wijzigingen verborgen zijn voor de gebruiker.

In het geval van een URL-omleiding verzendt Application Gateway een omleidingsreactie naar de client met de nieuwe URL. Dit betekent dat de client op zijn beurt de aanvraag opnieuw moet indienen bij 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 header met dezelfde naam heeft, zal het herschrijven van de waarde van een van deze headers ertoe leiden dat de andere headers in het antwoord worden neergeschreven. Dit kan meestal gebeuren met Set-Cookie header, omdat u meer dan één Set-Cookie in een antwoord kunt hebben. Een dergelijk scenario is wanneer u een app-service met een toepassingsgateway gebruikt en sessie-affiniteit op basis van cookies hebt geconfigureerd op de toepassingsgateway. In dit geval bevat het antwoord twee Set-Cookie headers: een die wordt gebruikt door de app-service, bijvoorbeeld: en een andere voor affiniteit met de Set-Cookie: ARRAffinity=ba127f1caf6ac822b2347cc18bba0364d699ca1ad44d20e0ec01ea80cda2a735;Path=/;HttpOnly;Domain=sitename.azurewebsites.net toepassingsgateway, bijvoorbeeld Set-Cookie: ApplicationGatewayAffinity=c1a2bd51lfd396387f96bl9cc3d2c516; Path=/ . Het herschrijven van een van Set-Cookie headers in dit scenario kan ertoe leiden dat de andere header Set-Cookie 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.
• Headernamen kunnen alfanumerieke tekens en specifieke symbolen bevatten, zoals gedefinieerd in RFC 7230. Het speciale teken onderstrepingsteken ( ) in headernamen wordt momenteel _ niet ondersteund.
• Verbindings- en upgradeheaders kunnen niet opnieuw worden geschreven

Volgende stappen

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