Skriva om HTTP-huvuden och URL med Application Gateway

Application Gateway kan du skriva om valt innehåll för begäranden och svar. Med den här funktionen kan du översätta URL:er, frågesträngsparametrar samt ändra begäran- och svarshuvuden. Du kan också lägga till villkor för att säkerställa att URL:en eller de angivna rubrikerna skrivs om endast när vissa villkor uppfylls. Dessa villkor baseras på informationen för begäran och svar.

Omskrivningstyper som stöds

Sidhuvuden för begäran och svar

MED HTTP-huvuden kan en klient och server skicka ytterligare information med en begäran eller ett svar. Genom att skriva om dessa huvuden kan du utföra viktiga uppgifter, till exempel lägga till säkerhetsrelaterade huvudfält som HSTS/X-XSS-Protection, ta bort svarshuvudfält som kan avslöja känslig information och ta bort portinformation från X-Forwarded-For-huvuden.

Med Application Gateway kan du lägga till, ta bort eller uppdatera HTTP-huvuden för begäran och svar när begäran- och svarspaketen flyttas mellan klientens och serverdelens pooler.

Information om hur du skriver om begärande- och svarshuvuden med Application Gateway med Azure Portal finns här.

Rubriker som stöds

Du kan skriva om alla huvuden i begäranden och svar, förutom anslutnings- och uppgraderingshuvudena. Du kan också använda programgatewayen för att skapa anpassade huvuden och lägga till dem i de begäranden och svar som dirigeras genom den.

URL-sökväg och frågesträng

Med url-omskrivningsfunktion i Application Gateway kan du:

• Skriva om värdnamnet, sökvägen och frågesträngen för begärande-URL:en

• Välj att skriva om URL:en för alla begäranden på en lyssnare eller bara de begäranden som matchar ett eller flera av de villkor som du anger. Dessa villkor baseras på egenskaperna för begäran och svar (begäran, huvud, svarshuvud och servervariabler).

• Välj att dirigera begäran (välj backend-pool) baserat på antingen den ursprungliga URL:en eller den omskrivna URL:en

Information om hur du skriver om URL med Application Gateway med Azure Portal finns här.

Skriva om åtgärder

Du använder omskrivningsåtgärder för att ange URL, begärandehuvuden eller svarshuvuden som du vill skriva om och det nya värdet som du vill skriva om dem till. Värdet för en URL eller en ny eller befintlig rubrik kan anges till följande typer av värden:

• Text
• Begärandehuvud. Om du vill ange ett begärandehuvud måste du använda syntaxen {http_req_ headerName}
• Svarshuvud. Om du vill ange ett svarshuvud måste du använda syntaxen {http_resp_ headerName}
• Servervariabel. Om du vill ange en servervariabel måste du använda syntaxen {var_ serverVariable}. Se listan över servervariabler som stöds
• En kombination av text, ett begärandehuvud, ett svarshuvud och en servervariabel.

Skriva om villkor

Du kan använda omskrivningsvillkor, en valfri konfiguration, för att utvärdera innehållet i HTTP(S)-begäranden och -svar och endast skriva om när ett eller flera villkor är uppfyllda. Programgatewayen använder dessa typer av variabler för att utvärdera innehållet i begäranden och svar:

• HTTP-huvuden i begäran
• HTTP-huvuden i svaret
• Application Gateway servervariabler

Du kan använda ett villkor för att utvärdera om en angiven variabel finns, om en angiven variabel matchar ett visst värde eller om en angiven variabel matchar ett visst mönster.

Mönstermatchning

Application Gateway använder reguljära uttryck för mönstermatchning i villkoret. Du kan använda PCRE-biblioteket (Perl Compatible Regular Expressions) för att konfigurera matchning av mönster för reguljära uttryck i villkoren. Mer information om syntax för reguljära uttryck finns på huvudsidan för Perl-reguljära uttryck.

Fånga

Om du vill samla in en delsträng för senare användning, placera parenteser runt undermönstret som matchar det i villkorets regex-definition. Det första par parentesparet lagrar sin delsträng i 1, det andra paret i 2 och så vidare. Du kan använda så många parenteser du vill; Perl fortsätter bara att definiera mer numrerade variabler så att du kan representera dessa avbildade strängar. Några exempel från ref:

• /(\d)(\d)/ # Matcha två siffror och samla in dem i grupperna 1 och 2

• /(\d+)/ # Matcha en eller flera siffror och samla in dem i grupp 1

• /(\d)+/ # Matcha en siffra en eller flera gånger och samla in den sista i grupp 1

När de har avbildats kan du referera till dem i åtgärdsuppsättningen med hjälp av följande format:

• För en avskiljning av begärandehuvuden måste du använda {http_req_headerName_groupNumber}. Till exempel {http_req_User-Agent_1} eller {http_req_User-Agent_2}
• För en infångade svarshuvud måste du använda {http_resp_headerName_groupNumber}. Till exempel {http_resp_Location_1} eller {http_resp_Location_2}
• För en servervariabel måste du använda {var_serverVariableName_groupNumber}. Till exempel {var_uri_path_1} eller {var_uri_path_2}

Om du vill använda hela värdet bör du inte nämna talet. Använd bara formatet {http_req_headerName}, osv. utan groupNumber.

Servervariabler

Application Gateway använder servervariabler för att lagra användbar information om servern, anslutningen till klienten och den aktuella begäran om anslutningen. Exempel på information som lagras är klientens IP-adress och webbläsartyp. Servervariabler ändras dynamiskt, till exempel när en ny sida läses in eller när ett formulär publiceras. Du kan använda dessa variabler för att utvärdera omskrivningsvillkor och skriva om rubriker. För att kunna använda värdet för servervariabler för att skriva om rubriker måste du ange dessa variabler i syntaxen {var_ serverVariableName}

Application Gateway stöder följande servervariabler:

Servervariabler för ömsesidig autentisering (förhandsversion)

Application Gateway stöder följande servervariabler för scenarier med ömsesidig autentisering. Använd dessa servervariabler på samma sätt som ovan med de andra servervariablerna.

Omskrivningskonfiguration

Om du vill konfigurera en omskrivningsregel måste du skapa en regeluppsättning för omskrivning och lägga till konfigurationen för omskrivningsregeln i den.

En regeluppsättning för omskrivning innehåller:

• Koppling av routningsregel för begäran: Omskrivningskonfigurationen är associerad med källlyssnaren via routningsregeln. När du använder en grundläggande routningsregel associeras omskrivningskonfigurationen med en källlyssnare och är en global omskrivning av rubrik. När du använder en sökvägsbaserad routningsregel definieras omskrivningskonfigurationen på URL-sökvägsmappningen. I så fall gäller den endast för det specifika sökvägsområdet för en plats. Du kan skapa flera omskrivningsuppsättningar och tillämpa varje omskrivningsuppsättning på flera lyssnare. Men du kan bara använda en omskrivningsuppsättning för en specifik lyssnare.

• Omskrivningsvillkor: Det är en valfri konfiguration. Omskrivningsvillkor utvärderar innehållet i HTTP(S)-begäranden och -svar. Omskrivningsåtgärden inträffar om HTTP(S)-begäran eller -svaret matchar omskrivningsvillkoret. Om du associerar mer än ett villkor med en åtgärd, sker åtgärden bara när alla villkor är uppfyllda. Med andra ord är åtgärden en logisk AND-åtgärd.

• Typ av omskrivning: Det finns tre typer av omskrivningar:

  • Skriva om begärandehuvuden
  • Skriva om svarshuvuden
  • Skriva om URL-komponenter
    • URL-sökväg: Värdet som sökvägen ska skrivas om till.
    • URL-frågesträng: Det värde som frågesträngen ska skrivas om till.
    • Omvärdera sökvägskarta: Används för att avgöra om URL-sökvägskartan ska utvärderas om eller inte. Om den behålls avmarkerad används den ursprungliga URL-sökvägen för att matcha sökvägsmönstret i URL-sökvägsmappningen. Om det är inställt på true (sant) utvärderas URL-sökvägskartan om för att kontrollera matchningen med den omskrivna sökvägen. Genom att aktivera den här växeln kan du dirigera begäran till en annan serverpool efter omskrivning.

Vanliga fallgropar vid omskrivningskonfiguration

• Aktivering av "Utvärdera sökvägskartan" tillåts inte för grundläggande regler för routning av förfrågningar. Detta är för att förhindra oändlig utvärderingsloop för en grundläggande routningsregel.

• Det måste finnas minst en regel för villkorlig omskrivning eller 1 omskrivningsregel som inte har "Utvärdera om sökvägsmappning" aktiverat för sökvägsbaserade routningsregler för att förhindra oändlig utvärderingsloop för en sökvägsbaserad routningsregel.

• Inkommande begäranden avslutas med en 500-felkod om en loop skapas dynamiskt baserat på klientindata. Den Application Gateway fortsätter att betjäna andra begäranden utan försämring i ett sådant scenario.

Använda URL-omskrivning eller omskrivning av värdhuvud med Web Application Firewall (WAF_v2 SKU)

När du konfigurerar url-omskrivning eller omskrivning av värdhuvud sker WAF-utvärderingen efter ändringen av begärandehuvudet eller URL-parametrarna (efter omskrivning). Och när du tar bort konfigurationen för omskrivning av URL-adress eller värdhuvud på din Application Gateway görs WAF-utvärderingen innan rubriken skrivs om (förskrivning). Den här ordningen säkerställer att WAF-reglerna tillämpas på den slutliga begäran som tas emot av din backend-pool.

Om du till exempel har följande regel för rubrikskrivning för rubriken – om värdet för rubriken är lika med skriver du om "Accept" : "text/html" "Accept" värdet till "text/html" "image/png" .

Här, när endast rubrikreskrivning har konfigurerats, görs WAF-utvärderingen på "Accept" : "text/html" . Men när du konfigurerar URL-omskrivning eller omskrivning av värdhuvud görs WAF-utvärderingen på "Accept" : "image/png" .

Vanliga scenarier för omskrivning av huvud

Ta bort portinformation från huvudet X-Forwarded-For

Application Gateway in en X-Forwarded-For-rubrik i alla begäranden innan den vidarebefordrar begäranden till backend. Det här huvudet är en kommaavgränsad lista över IP-portar. Det kan finnas scenarier där backend-servrarna bara behöver huvudena som innehåller IP-adresser. Du kan använda omskrivning av sidhuvud för att ta bort portinformationen från huvudet X-Forwarded-For. Ett sätt att göra detta är att ange huvudet till add_x_forwarded_for_proxy servervariabeln. Du kan också använda variabeln client_ip:

Ändra en omdirigerings-URL

När ett backend-program skickar ett omdirigeringssvar kanske du vill omdirigera klienten till en annan URL än den som anges av backend-programmet. Du kanske till exempel vill göra detta när en apptjänst finns bakom en programgateway och kräver att klienten gör en omdirigering till den relativa sökvägen. (Till exempel en omdirigering från contoso.azurewebsites.net/path1 till contoso.azurewebsites.net/path2.)

Eftersom App Service är en tjänst för flera klienttjänster används värdhuvudet i begäran för att dirigera begäran till rätt slutpunkt. App Services har standarddomännamnet .azurewebsites.net (till exempel contoso.azurewebsites.net) som skiljer sig från programgatewayens domännamn * (till exempel contoso.com). Eftersom den ursprungliga begäran från klienten har programgatewayens domännamn (contoso.com) som värdnamn, ändrar programgatewayen värdnamnet till contoso.azurewebsites.net. Den gör den här ändringen så att App Service kan dirigera begäran till rätt slutpunkt.

När App Service skickar ett omdirigeringssvar använder den samma värdnamn i platshuvudet för svaret som i begäran som den tar emot från Application Gateway. Klienten skickar därför begäran direkt till i contoso.azurewebsites.net/path2 stället för att gå via programgatewayen ( contoso.com/path2 ). Det är inte önskvärt att kringgå programgatewayen.

Du kan lösa det här problemet genom att ange värdnamnet i platsrubriken till programgatewayens domännamn.

Här är stegen för att ersätta värdnamnet:

1. Skapa en omskrivningsregel med ett villkor som utvärderar om platshuvudet i svaret innehåller azurewebsites.net. Ange mönstret (https?):\/\/.*azurewebsites\.net(.*)$ .
2. Utför en åtgärd för att skriva om platsrubriken så att den har programgatewayens värdnamn. Gör detta genom att {http_resp_Location_1}://contoso.com{http_resp_Location_2} ange som rubrikvärde. Du kan också använda servervariabeln för att host ange värdnamnet så att det matchar den ursprungliga begäran.

Implementera HTTP-säkerhetshuvuden för att förhindra sårbarheter

Du kan åtgärda flera säkerhetsproblem genom att implementera nödvändiga rubriker i programsvaret. Dessa säkerhetshuvuden omfattar X-XSS-Protection, Strict-Transport-Security och Content-Security-Policy. Du kan använda Application Gateway för att ange dessa huvuden för alla svar.

Ta bort oönskade rubriker

Du kanske vill ta bort huvuden som visar känslig information från ett HTTP-svar. Du kanske till exempel vill ta bort information som serverservernamn, operativsystem eller biblioteksinformation. Du kan använda programgatewayen för att ta bort dessa huvuden:

Kontrollera förekomsten av en rubrik

Du kan utvärdera en HTTP-begäran eller ett svarshuvud för förekomsten av ett huvud eller en servervariabel. Den här utvärderingen är användbar när du bara vill skriva om en rubrik när en viss rubrik finns.

Vanliga scenarier för URL-omskrivning

Val av parameterbaserad sökväg

Om du vill utföra scenarier där du vill välja serverdelspoolen baserat på värdet för en rubrik, en del av URL:en eller frågesträngen i begäran kan du använda en kombination av url-omskrivningsfunktioner och sökvägsbaserad routning. Om du till exempel har en shoppingwebbplats och produktkategorin skickas som frågesträng i URL:en och du vill dirigera begäran till backend baserat på frågesträngen gör du följande:

Steg 1: Skapa en sökvägskarta enligt bilden nedan

Steg 2 (a): Skapa en omskrivningsuppsättning som har 3 omskrivningsregler:

• Den första regeln har ett villkor som kontrollerar query_string-variabeln för category=shoes och har en åtgärd som skriver om URL-sökvägen till /listing1 och har Omvärdera sökvägskarta aktiverad

• Den andra regeln har ett villkor som kontrollerar query_string-variabeln för category=bag och har en åtgärd som skriver om URL-sökvägen till /listing2 och har Omvärdera sökvägsmappning aktiverad

• Den tredje regeln har ett villkor som kontrollerar query_string-variabeln för category=accessories och har en åtgärd som skriver om URL-sökvägen till /listing3 och har Omvärdera sökvägsmappning aktiverad

Steg 2 (b): Associera den här omskrivningsuppsättningen med standardsökvägen för ovanstående sökvägsbaserade regel

Om användaren nu begär contoso.com/listing?category=any matchas den med standardsökvägen eftersom inget av sökvägsmönstren i sökvägskartan (/listing1, /listing2, /listing3) matchar. Eftersom du har associerat ovanstående omskrivningsuppsättning med den här sökvägen utvärderas den här omskrivningsuppsättningen. Eftersom frågesträngen inte matchar villkoret i någon av de tre omskrivningsreglerna i den här omskrivningsuppsättningen sker ingen omskrivningsåtgärd och därför dirigeras begäran oförändrad till den backend som är associerad med standardsökvägen (som är GenericList).

Om användaren begär contoso.com/listing?category=shoes matchas standardsökvägen igen. Men i det här fallet kommer villkoret i den första regeln att matcha och därför körs åtgärden som är associerad med villkoret, vilket skriver om URL-sökvägen till /listing1 och utvärderar sökvägskartan på ett annat sätt. När sökvägskartan omvärderas kommer begäran nu att matcha sökvägen som är associerad med mönstret /listing1 och begäran dirigeras till den backend som är associerad med det här mönstret, vilket är ShoesListBackendPool.

Skriva om frågesträngsparametrar baserat på URL:en

Tänk dig ett scenario med en shoppingwebbplats där användarens synliga länk ska vara enkel och läsbar, men backend-servern behöver frågesträngparametrarna för att visa rätt innehåll.

I så fall kan Application Gateway hämta parametrar från URL:en och lägga till nyckel/värde-par för frågesträngar från dem från URL:en. Anta till exempel att användaren vill skriva om, till , det kan uppnås via följande konfiguration för https://www.contoso.com/fashion/shirts https://www.contoso.com/buy.aspx?category=fashion&product=shirts URL-omskrivning.

Villkor – Om uri_path servervariabeln är lika med mönstret /(.+)/(.+)

Åtgärd – Ange URL-sökväg till buy.aspx och frågesträng till category={var_uri_path_1}&product={var_uri_path_2}

En stegvis guide för att uppnå scenariot som beskrivs ovan finns i Skriva om URL med hjälp Application Gateway med Azure Portal

URL-omskrivning jämfört med url-omdirigering

När det gäller en URL-Application Gateway skriver om URL:en innan begäran skickas till backend-adressen. Detta ändrar inte vad användarna ser i webbläsaren eftersom ändringarna är dolda för användaren.

Om en URL omdirigeras skickar Application Gateway ett omdirigeringssvar till klienten med den nya URL:en. Det kräver i sin tur att klienten skickar sin begäran på nytt till den nya URL:en som anges i omdirigeringen. Den URL som användaren ser i webbläsaren uppdateras till den nya URL:en.

Begränsningar

• Om ett svar har fler än en rubrik med samma namn kommer omskrivning av värdet för en av dessa huvuden att resultera i att de andra huvudena i svaret blir borttryckt. Detta kan vanligtvis inträffa med Set-Cookie huvud eftersom du kan ha fler än en Set-Cookie i ett svar. Ett sådant scenario är när du använder en apptjänst med en programgateway och har konfigurerat cookiebaserad sessionstillhörighet på programgatewayen. I det här fallet innehåller svaret två Set-Cookie huvuden: en som används av apptjänsten, till exempel: och en annan för Set-Cookie: ARRAffinity=ba127f1caf6ac822b2347cc18bba0364d699ca1ad44d20e0ec01ea80cda2a735;Path=/;HttpOnly;Domain=sitename.azurewebsites.net Application Gateway-tillhörighet, till exempel Set-Cookie: ApplicationGatewayAffinity=c1a2bd51lfd396387f96bl9cc3d2c516; Path=/ . Om du skriver om en av Set-Cookie-huvudena i det här scenariot kan det leda till att den andra Set-Cookie-huvudet tas bort från svaret.
• Omwrites stöds inte när programgatewayen har konfigurerats för att omdirigera begäranden eller för att visa en anpassad felsida.
• Rubriknamn kan innehålla alla alfanumeriska tecken och specifika symboler enligt definitionen i RFC 7230. Vi stöder för närvarande inte specialtecknet ( _ ) i Rubriknamn.
• Anslutnings- och uppgraderingshuvuden kan inte skrivas om

Nästa steg

• Lär dig hur du skriver om HTTP-huvuden med Application Gateway med Azure Portal
• Lär dig hur du skriver om URL med Application Gateway med Azure Portal