Umschreiben von HTTP-Headern und einer URL mithilfe von Application Gateway
Mit Application Gateway können Sie den ausgewählten Inhalt von Anforderungen und Antworten umschreiben. Mit diesem Feature können Sie URLs übersetzen, Zeichenfolgenparameter abfragen und Anforderungs- und Antwortheader ändern. Außerdem können Sie Bedingungen hinzufügen, um sicherzustellen, dass die URL oder die angegebenen Header nur dann neu generiert werden, wenn bestimmte Bedingungen erfüllt sind. Diese Bedingungen basieren auf den Anforderungs- und Antwortinformationen.
Die Features zum Umschreiben von HTTP-Headern und URLs sind nur für die Application Gateway v2-SKU verfügbar.
Anforderungs- und Antwortheader
Application Gateway ermöglicht Ihnen das Hinzufügen, Entfernen oder Aktualisieren von HTTP-Anforderungs- und -Antwortheadern, während die Anforderungs-/Antwortpakete zwischen dem Client und den Back-End-Pools verschoben werden. HTTP-Header ermöglichen einem Client und Server das Übergeben von zusätzlichen Informationen mit einer Anforderung oder Antwort. Durch das erneute Generieren dieser HTTP-Header können Sie verschiedene wichtige Aufgaben umsetzen, z.B. das Hinzufügen von sicherheitsbezogenen Headerfeldern wie HSTS/X-XSS-Protection, das Entfernen von Antwortheaderfeldern, über die sensible Informationen offengelegt werden können, und das Entfernen von Portinformationen aus X-Forwarded-For-Headern.
Sie können alle Header in Anforderungen und Antworten mit Ausnahme von Connection- und Upgrade-Headern umschreiben. Sie können auch über das Anwendungsgateway benutzerdefinierte Header erstellen und sie den Anforderungen und Antworten hinzufügen, die über das Gateway weitergeleitet werden. Informationen zum Umschreiben von Anforderungs- und Antwortheadern mit Application Gateway über das Azure-Portal finden Sie hier.
URL-Pfad und Abfragezeichenfolge
Mit der Funktion zum Umschreiben einer URL in Application Gateway können Sie folgende Aktionen ausführen:
Umschreiben von Hostnamen, Pfad und Abfragezeichenfolge der Anforderungs-URL
Wählen Sie aus, ob Sie die URLs aller Anforderungen eines Listeners oder nur die Anforderungen umschreiben möchten, die einer oder mehreren festgelegten Bedingungen entsprechen. Diese Bedingungen basieren auf den Anforderungseigenschaften (Anforderungsheader und Servervariablen).
Weiterleiten der Anforderung (Auswählen des Back-End-Pools) basierend auf der ursprünglichen URL oder der neu generierten URL
Informationen zum Umschreiben der URL mit Application Gateway über das Azure-Portal finden Sie hier.
Grundlegendes zu Umschreibungen in Application Gateway
Ein Umschreibungssatz ist eine Sammlung einer Routingregel, einer Bedingung und einer Aktion.
Zuordnung der Routingregel für die Anforderung: Die Konfiguration für das Umschreiben wird einem Quelllistener über seine Routingregel zugeordnet. Bei Verwendung einer Routingregel vom Typ „Basic“ wird die Konfiguration für das Umschreiben dem Quelllistener zugeordnet und fungiert als globale Umschreibung. Bei Verwendung einer pfadbasierten Routingregel wird die Konfiguration für das Umschreiben gemäß der URL-Pfadzuordnung definiert. Im letzteren Fall gilt sie nur für einen bestimmten Pfadbereich einer Site. Sie können einen Umschreibungssatz auf mehrere Routingregeln anwenden, aber eine Routingregel kann nur eine Umschreibung zugeordnet haben.
Bedingung für das Umschreiben: Dies ist eine optionale Konfiguration. Basierend auf den von Ihnen definierten Bedingungen wertet Application Gateway die Inhalte der HTTP(S)-Anforderungen und -Antworten aus. Die nachfolgende „Umschreibungsaktion“ wird ausgeführt, wenn die HTTP(S)-Anforderung oder -Antwort die Bedingung erfüllt. Wenn Sie der Aktion mehr als eine Bedingung zuordnen, erfolgt die Aktion nur, wenn alle Bedingungen erfüllt sind. Mit anderen Worten, es handelt sich um eine logische UND-Operation. Sie können Umschreibungsbedingungen verwenden, um den Inhalt von HTTP(S)-Anforderungen und -Antworten auszuwerten. Mit dieser optionalen Konfiguration können Sie eine Umschreibung nur dann durchführen, wenn mindestens eine Bedingung erfüllt ist. Das Anwendungsgateway wertet mit diesen Typen von Variablen den Inhalt von Anforderungen und Antworten aus:
Sie können die folgenden Typen auswählen, um nach einer Bedingung zu suchen:
- HTTP-Header (Anforderung und Antwort)
- Unterstützte Servervariablen
Mit einer Bedingung können Sie auswerten, ob angegebene Header oder Variablen vorhanden sind, indem Sie ihre Werte über Text oder ein RegEx-Muster abgleichen. Bei erweiterten Konfigurationen für das Umschreiben können Sie auch den Wert der Header- oder Servervariable für die spätere Verwendung unter „Umschreibungsaktion“ erfassen. Erfahren Sie mehr über Muster und Erfassung.
Umschreibungsaktion: Der Aktionssatz für das Umschreiben ermöglicht es Ihnen, Header (Anforderung oder Antwort) oder die URL-Komponenten umzuschreiben.
Eine Aktion kann die folgenden Werttypen oder deren Kombinationen aufweisen:
- Text.
- Wert des Anforderungsheaders – Um einen erfassten Anforderungsheaderwert zu verwenden, geben Sie die Syntax als
{http_req_headerName}an. - Wert des Antwortheaders – Um einen erfassten Antwortheaderwert aus der vorherigen Bedingung zu verwenden, geben Sie die Syntax als
{http_resp_headerName}an. Sie können{capt_header_value_matcher}verwenden, wenn der Wert aus dem Antwortheader „Set-Cookie“ des Aktionssatzes erfasst wird. Erfahren Sie mehr über Erfassen unter Aktionssatz. - Servervariable – Um eine Servervariable zu verwenden, geben Sie die Syntax als
{var_serverVariable}an. Liste mit den unterstützten Servervariablen.
Wenn Sie eine Aktion zum Umschreiben einer URL verwenden, werden die folgenden Vorgänge unterstützt:
- URL-Pfad: Der neue Wert, der als Pfad festgelegt werden soll.
- URL-Abfragezeichenfolge: Der neue Wert, in den die Abfragezeichenfolge umgeschrieben werden muss.
- Pfadzuordnung erneut auswerten: Geben Sie an, ob die URL-Pfadzuordnung nach dem Umschreiben erneut ausgewertet werden muss. Wenn diese Option deaktiviert bleibt, wird der ursprüngliche URL-Pfad verwendet, um eine Übereinstimmung für das Pfadmuster in der URL-Pfadzuordnung zu ermitteln. Wenn diese Option auf TRUE festgelegt ist, wird die URL-Pfadzuordnung erneut ausgewertet, um die Übereinstimmung mit dem umgeschriebenen Pfad zu überprüfen. Das Aktivieren dieses Schalters hilft beim Routing der Anforderung an einen anderen Back-End-Pool nach dem Umschreiben.
Musterabgleich und -erfassung
Musterabgleich und -erfassung werden unter „Bedingung“ und „Aktion“ unterstützt (unter „Aktion“ werden sie nur für einen bestimmten Header unterstützt).
Musterabgleich
Application Gateway verwendet reguläre Ausdrücke für den Musterabgleich. Sie sollten für Regular Expression 2 (RE2) kompatible Ausdrücke verwenden, wenn Sie die Syntax für Ihren Musterabgleich schreiben.
Sie können den Musterabgleich sowohl unter „Bedingung“ als auch „Aktion“ verwenden.
- Bedingung: Dies wird verwendet, um die Werte für eine Header- oder Servervariable abzugleichen. Verwenden Sie zum Abgleichen eines Musters unter „Bedingungen“ die Eigenschaft „pattern“.
- Aktion: Der Musterabgleich unter „Aktionssatz“ ist nur für den Antwortheader „Set-Cookie“ verfügbar. Verwenden Sie die Eigenschaft „HeaderValueMatcher“, um ein Muster für „Set-Cookie“ unter einer Aktion abzugleichen. Falls erfasst, kann der Wert als {capt_header_value_matcher} verwendet werden. Da „Set-Cookie“ mehrfach vorhanden sein kann, können Sie mit einem Mustervergleich hier nach einem bestimmten Cookie suchen. Beispiel: Für eine bestimmte Version des Benutzer-Agents möchten Sie den Set-Cookie-Antwortheader für „cookie2“ mit max-age=3600 (eine Stunde) umschreiben. In diesem Fall verwenden Sie
- Bedingung – Typ: Anforderungsheader, Headername: Benutzer-Agent, Muster zum Abgleichen: *2.0
- Aktion – Umschreibungstyp: Antwortheader, Aktionstyp: Set, Headername: Set-Cookie, Headerwert-Matcher: cookie2=(.*), Headerwert: cookie2={capt_header_value_matcher_1}; Max-Age=3600
Hinweis
Wenn Sie eine Application Gateway Webanwendungsfirewall (WAF) mit Core Rule Set 3.1 oder früher ausführen, treten möglicherweise Probleme auf, wenn Sie Perl-kompatible reguläre Ausdrücke (PCRE) verwenden, während Sie Lookahead- und Lookbehind-Assertionen (negative oder positive) ausführen.
Syntax für die Erfassung
Muster können auch verwendet werden, um eine Teilzeichenfolge für die spätere Verwendung zu erfassen. Platzieren Sie Klammern um ein Teilmuster in der RegEx-Definition. Das erste Paar von Klammern speichert die Teilzeichenfolge im Register 1, das zweite Paar in 2 usw. Sie können beliebig viele Klammern verwenden. Perl definiert immer mehr nummerierte Variablen, mit denen Sie diese erfassten Zeichenfolgen darstellen können. In diesem Perl-Programmierleitfaden können Sie einige Beispiel finden.
- (\d)(\d) # – entspricht zwei Ziffern, die in den Gruppen 1 und 2 erfasst werden
- (\d+) # – entspricht einer oder mehrere Ziffern, die alle in Gruppe 1 erfasst werden
- (\d)+ # – entspricht einer Ziffer ein- oder mehrmals und erfasst die letzte Entsprechung in Gruppe 1
Nach der Erfassung können Sie sie im Aktionssatzwert mit dem folgenden Format verwenden:
- Bei der Erfassung eines Anforderungsheaders müssen Sie {http_req_Headername_Gruppennummer} verwenden, z. B. {http_req_User-Agent_1} oder {http_req_User-Agent_2}
- Bei der Erfassung eines Antwortheaders müssen Sie {http_resp_Headername_Gruppennummer} verwenden, Beispiel: {http_resp_Location_1} oder {http_resp_Location_2}. Wohingegen Sie für einen Antwortheader „Set-Cookie“, der über die Eigenschaft „HeaderValueMatcher“ erfasst wurde, {capt_header_value_matcher_groupNumber} verwenden müssen. Beispiel: {capt_header_value_matcher_1} oder {capt_header_value_matcher_2}.
- Für eine Servervariable müssen Sie {var_Servervariablenname_Gruppennummer} verwenden, z. B. {var_uri_path_1} oder {var_uri_path_2}
Hinweis
- Die Verwendung von / als Präfix und Suffix für das Muster sollte nicht im Muster angegeben werden, um dem Wert zu entsprechen. Beispielsweise wird (\d)(\d) mit zwei Ziffern übereinstimmen. /(\d)(\d)/ wird nicht mit zwei Ziffern übereinstimmen.
- Der Fall der Bedingungsvariablen muss der Fall der Erfassungsvariablen entsprechen. Wenn meine Bedingungsvariable beispielsweise „User-Agent“ ist, muss meine Erfassungsvariable „User-Agent“ enthalten (d. h. {http_req_User-Agent_2}). Wenn meine Bedingungsvariable beispielsweise als „User-Agent“ definiert ist, muss meine Erfassungsvariable „User-Agent“ enthalten (d. h. {http_req_user-agent_2}).
- Wenn Sie den gesamten Wert verwenden möchten, sollten Sie die Nummer nicht angeben. Verwenden Sie einfach das Format {http_req_Headername} usw. ohne die Gruppennummer.
Servervariablen
Application Gateway speichert mit Servervariablen nützliche Informationen zum Server, zur Verbindung mit dem Client und zur momentanen Anforderung an die Verbindung. Beispiele für gespeicherte Informationen sind die IP-Adresse und der Webbrowsertyp des Clients. Servervariablen ändern sich dynamisch, wenn z.B. eine neue Seite geladen oder ein Formular gesendet wird. Anhand dieser Variablen können Sie Bedingungen für das erneute Generieren und Header für das erneute Generieren auswerten. Um den Wert von Servervariablen zum Umschreiben von Headern zu verwenden, müssen Sie diese Variablen in der Syntax {var_serverVariableName} angeben.
Das Application Gateway unterstützt die folgenden Servervariablen:
| Variablenname | Beschreibung |
|---|---|
| add_x_forwarded_for_proxy | Das Headerfeld „X-Forwarded-For“ der Clientanforderung mit der Variable client_ip (in dieser Tabelle unten erläutert), die im Format IP1, IP2, IP3 usw. angefügt ist. Ist das Feld „X-Forwarded-For“ im Clientanforderungsheader nicht vorhanden, ist die Variable add_x_forwarded_for_proxy gleich der Variablen $client_ip. Diese Variable ist hilfreich, wenn Sie den Header „X-Forwarded-For“ umschreiben möchten, der von Application Gateway festgelegt wurde, sodass der Header nur die IP-Adresse und keine Portinformationen enthält. |
| ciphers_supported | Eine Liste der Verschlüsselungen, die vom Client unterstützt werden. |
| ciphers_used | Die Verschlüsselungszeichenfolge, die für eine eingerichtete TLS-Verbindung verwendet wird. |
| client_ip | Die IP-Adresse des Clients, von dem das Anwendungsgateway die Anforderung empfangen hat. Befindet sich ein Reverseproxy vor dem Anwendungsgateway und dem Ursprungsclient, gibt client_ip die IP-Adresse des Reverseproxys zurück. |
| client_port | Der Port des Clients. |
| client_tcp_rtt | Informationen zur TCP-Verbindung des Clients. Verfügbar auf Systemen, die die Socketoption „TCP_INFO“ unterstützen. |
| client_user | Wenn HTTP-Authentifizierung verwendet wird, der Benutzername, der bei der Authentifizierung angegeben wird. |
| host | In dieser Reihenfolge: Hostname aus der Anforderungszeile, Hostname aus dem Anforderungsheaderfeld „Host“ oder der Servername, der mit einer Anforderung übereinstimmt. Beispiel: In der Anforderung http://contoso.com:8080/article.aspx?id=123&title=fabrikam lautet der Hostwert contoso.com. |
| cookie_Name | Das name-Cookie. |
| http_method | Die Methode, die für die URL-Anforderung verwendet wird. Beispielsweise GET oder POST. |
| http_status | Der Sitzungsstatus. Beispielsweise 200, 400 oder 403. |
| http_version | Das Anforderungsprotokoll. In der Regel HTTP/1.0, HTTP/1.1 oder HTTP/2.0. |
| query_string | Die Liste der Variablen/Wert-Paare nach dem „?“ in der angeforderten URL. Beispiel: In der Anforderung http://contoso.com:8080/article.aspx?id=123&title=fabrikam lautet der Wert von „query_string“ id=123&title=fabrikam. |
| received_bytes | Die Länge der Anforderung (einschließlich Anforderungszeile, Header und Anforderungstext). |
| request_query | Die Argumente in der Anforderungszeile. |
| request_scheme | Das Anforderungsschema: „http“ oder „https“. |
| request_uri | Der vollständige ursprüngliche Anforderungs-URI (mit Argumenten). Beispiel: In der Anforderung http://contoso.com:8080/article.aspx?id=123&title=fabrikam* lautet der Wert von „request_uri“ /article.aspx?id=123&title=fabrikam. |
| sent_bytes | Die Anzahl der an einen Client gesendeten Bytes. |
| server_port | Der Port des Servers, der eine Anforderung akzeptiert hat. |
| ssl_connection_protocol | Das Protokoll einer hergestellten TLS-Verbindung. |
| ssl_enabled | „On“, wenn die Verbindung im TLS-Modus ausgeführt wird. Andernfalls eine leere Zeichenfolge. |
| uri_path | Identifiziert die bestimmte Ressource auf dem Host, auf die der Webclient zugreifen möchte. Die Variable verweist auf den ursprünglichen URL-Pfad vor etwaigen Änderungen. Dies ist der Teil des Anforderungs-URI ohne die Argumente. In der Anforderung http://contoso.com:8080/article.aspx?id=123&title=fabrikam lautet der Wert von „uri_path“ z. B. /article.aspx. |
Servervariablen für die gegenseitige Authentifizierung
Application Gateway unterstützt die folgenden Servervariablen für Szenarien der gegenseitigen Authentifizierung. Verwenden Sie diese Servervariablen auf die gleiche Weise wie die oben beschriebenen anderen Servervariablen.
| Variablenname | Beschreibung |
|---|---|
| client_certificate | Das Clientzertifikat im PEM-Format für eine hergestellte SSL-Verbindung. |
| client_certificate_end_date | Das Enddatum des Clientzertifikats. |
| client_certificate_fingerprint | Der SHA1-Fingerabdruck des Clientzertifikats für eine hergestellte SSL-Verbindung. |
| client_certificate_issuer | Die Zeichenfolge „Aussteller-DN“ des Clientzertifikats für eine hergestellte SSL-Verbindung. |
| client_certificate_serial | Die Seriennummer des Clientzertifikats für eine hergestellte SSL-Verbindung. |
| client_certificate_start_date | Das Startdatum des Clientzertifikats. |
| client_certificate_subject | Die Zeichenfolge „Antragsteller-DN“ des Clientzertifikats für eine hergestellte SSL-Verbindung. |
| client_certificate_verification | Das Ergebnis der Überprüfung des Clientzertifikats: SUCCESS, FAILED:<reason> oder NONE, wenn kein Zertifikat vorhanden war. |
Häufige Szenarien für die Headerumschreibungen
Entfernen von Portinformationen aus dem X-Forwarded-For-Header
Application Gateway fügt in alle Anforderungen einen X-Forwarded-For-Header ein, bevor es die Anforderungen an das Back-End weiterleitet. Dieser Header ist eine durch Trennzeichen getrennte Liste von IP-Ports. Es gibt möglicherweise Szenarien, in denen Back-End-Server in den Headern nur IP-Adressen benötigen. Sie können mit dem erneuten Generieren von Headern die Portinformationen aus dem X-Forwarded-For-Header entfernen. Dies kann beispielsweise erreicht werden, indem der Header auf die Servervariable „add_x_forwarded_for_proxy“ festgelegt wird. Alternativ können Sie auch die Variable „client_ip“ verwenden:
Ändern einer Umleitungs-URL
Das Ändern einer Umleitungs-URL kann unter bestimmten Umständen nützlich sein. Beispiel: Clients wurden ursprünglich zu einem Pfad wie „/blog“ umgeleitet, sollten aber jetzt aufgrund einer Änderung der Inhaltsstruktur an „/updates“ gesendet werden.
Warnung
Die Notwendigkeit, eine Umleitungs-URL zu ändern, tritt manchmal im Kontext einer Konfiguration auf, bei der Application Gateway so konfiguriert ist, dass der Hostname gegenüber dem Back-End überschrieben wird. Der Hostname, der gegenüber des Back-Ends angezeigt wird, unterscheidet sich in diesem Fall vom Hostnamen, der gegenüber des Browsers angezeigt wird. In diesem Fall würde bei der Umleitung nicht der richtige Hostnamen verwendet werden. Diese Konfiguration wird nicht empfohlen.
Die Einschränkungen und Auswirkungen einer solchen Konfiguration werden unter Beibehalten des ursprünglichen HTTP-Hostnamens zwischen einem Reverseproxy und seiner Back-End-Webanwendung beschrieben. Das empfohlene Setup für App Service besteht darin, die Anweisungen für Benutzerdefinierte Domäne (empfohlen) unter Konfigurieren von App Service mit Application Gateway zu befolgen. Das Umschreiben des location-Headers in der Antwort, wie im folgenden Beispiel beschrieben, sollte als Problemumgehung betrachtet werden – es behebt nicht die Grundursache.
Wenn der App Service eine Umleitungsantwort sendet, verwendet er den gleichen Hostnamen im Adressheader seiner Antwort wie in der Anforderung, die er vom Anwendungsgateway empfängt. Der Client sendet die Anforderung direkt an contoso.azurewebsites.net/path2 und durchläuft nicht das Anwendungsgateway (contoso.com/path2). Das Umgehen des Anwendungsgateways ist nicht wünschenswert.
Sie können dieses Problem durch Festlegen des Hostnamens im Adressheader des Anwendungsgateway-Domänennamens lösen.
Hier sind die Schritte zum Ersetzen des Hostnamens:
Erstellen Sie eine Regel zum erneuten Generieren mit einer Bedingung, die prüft, ob der Adressheader in der Antwort „azurewebsites.net“ enthält. Geben Sie das Muster
(https?):\/\/.*azurewebsites\.net(.*)$ein.Führen Sie eine Aktion zum erneuten Generieren des Adressheaders durch, damit sie den Hostnamen des Anwendungsgateways hat. Geben Sie hierzu
{http_resp_Location_1}://contoso.com{http_resp_Location_2}als Headerwert ein. Alternativ können Sie auch die Servervariablehostverwenden, um den Hostnamen entsprechend der ursprünglichen Anforderung festzulegen.
Implementieren von HTTP-Sicherheitsheadern, um Sicherheitsrisiken zu verhindern
Sie können verschiedene Sicherheitsrisiken beheben, indem Sie die erforderlichen Header in die Anwendungsantwort implementieren. Zu diesen Sicherheitsheadern zählen X-XSS-Protection, Strict-Transport-Security und Content-Security-Policy. Über Application Gateway können Sie diese Header für alle Antworten festlegen.
Löschen von unerwünschten Headern
Möglicherweise möchten Sie Header entfernen, die vertrauliche Informationen aus einer HTTP-Antwort anzeigen. Beispielsweise möchten Sie möglicherweise Informationen wie den Namen des Back-End-Servers, das Betriebssystem oder die Bibliothek entfernen. Sie können diese Header mit dem Anwendungsgateway entfernen:
Es ist nicht möglich, eine Umschreibungsregel zum Löschen des Hostheaders zu erstellen. Wenn Sie versuchen, eine Umschreibungsregel zu erstellen, bei der die Aktionsart auf „Löschen“ und der Header auf „Host“ festgelegt wird, tritt ein Fehler auf.
Überprüfen des Vorhandenseins eines Headers
Sie können einen HTTP-Anforderungs- oder -Antwortheader auf das Vorhandensein einer Header- oder Servervariablen untersuchen. Diese Untersuchung ist hilfreich, wenn Sie nur dann erneut Header generieren möchten, wenn der betreffende Header auch vorhanden ist.
Häufige Szenarien für die URL-Umschreibungen
Parameterbasierte Pfadauswahl
Für Szenarien, in denen Sie den Back-End-Pool basierend auf dem Wert eines Headers, auf einem Teil der URL oder auf der Abfragezeichenfolge in der Anforderung auswählen möchten, können Sie eine Kombination aus URL-Rewrite-Funktionalität und pfadbasiertem Routing verwenden.
Erstellen Sie dazu einen Rewrite-Satz mit einer Bedingung, die nach einem bestimmten Parameter sucht (Abfragezeichenfolge, Header usw.), und dann eine Aktion ausführt, bei der sie den URL-Pfad ändert (stellen Sie sicher, dass Neuauswerten der Pfadzuordnung aktiviert ist). Der Rewrite-Satz muss dann einer pfadbasierten Regel zugeordnet werden. Die pfadbasierte Regel muss die gleichen URL-Pfade enthalten, die im Rewrite-Satz und dem entsprechenden Back-End-Pool angegeben sind.
Mit dem Rewrite-Satz können Benutzer daher nach einem bestimmten Parameter suchen und ihm einen neuen Pfad zuweisen, und mit der pfadbasierten Regel können Benutzer diesen Pfaden Back-End-Pools zuweisen. Solange „Neuauswerten der Pfadzuordnung“ aktiviert ist, wird der Datenverkehr auf der Grundlage des im Rewrite-Satzes angegebenen Pfads weitergeleitet.
Ein Anwendungsfallbeispiel mithilfe von Abfragezeichenfolgen finden Sie unter Weiterleiten von Datenverkehr mithilfe von parameterbasierter Pfadauswahl im Portal.
Umschreiben von Abfragezeichenfolgenparametern basierend auf der URL
Gehen Sie vom Szenario einer Verkaufswebsite aus, auf der der für Benutzer sichtbare Link einfach und lesbar sein sollte, während hingegen der Back-End-Server die Abfragezeichenfolgenparameter benötigt, um den richtigen Inhalt anzuzeigen.
In diesem Fall kann Application Gateway Parameter aus der URL erfassen und der Abfragezeichenfolge Schlüssel-Wert-Paare aus der URL hinzufügen. Nehmen Sie beispielsweise an, der Benutzer möchte https://www.contoso.com/fashion/shirts in https://www.contoso.com/buy.aspx?category=fashion&product=shirts umschreiben. Dies kann durch die folgende URL-Umschreibungskonfiguration erreicht werden.
Bedingung: Servervariable uri_path entspricht dem Muster /(.+)/(.+)
Aktion: Festlegen des URL-Pfads auf buy.aspx und der Abfragezeichenfolge auf category={var_uri_path_1}&product={var_uri_path_2}
Eine Schrittanleitung für das oben beschriebene Szenario finden Sie unter Erneutes Generieren einer URL mit Azure Application Gateway: Azure-Portal
Häufige Probleme bei der Konfiguration der Umschreibung (Rewrite)
Das Aktivieren von „Pfadzuordnung neu auswerten“ ist für grundlegende Anforderungsroutingregeln nicht zulässig. So wird eine Endlosschleife bei der Auswertung einer grundlegenden Routingregel verhindert.
Es muss mindestens eine bedingte Umschreibungsregel oder eine Umschreibungsregel vorhanden sein, für die „Pfadzuordnung neu auswerten“ für pfadbasierte Routingregeln nicht aktiviert ist, um eine Endlosschleife bei der Auswertung einer pfadbasierten Routingregel zu verhindern.
Eingehende Anforderungen werden mit Fehlercode 500 beendet, wenn eine Schleife dynamisch basierend auf Clienteingaben erstellt wird. In einem solchen Szenario setzt die Application Gateway-Instanz die Verarbeitung anderer Anforderungen ohne Leistungsminderung fort.
Verwenden der Umschreibung von URLs (URL-Rewrite) oder Hostheadern mit Web Application Firewall (WAF_v2 SKU)
Wenn Sie das Umschreiben von URLs oder Hostheadern konfigurieren, erfolgt die WAF-Auswertung nach der Änderung der Anforderungsheader- oder URL-Parameter, d. h. nach dem Umschreiben. Wenn Sie die Umschreibungskonfiguration von URLs oder Hostheadern auf der Application Gateway-Instanz entfernen, erfolgt die WAF-Auswertung vor dem Umschreiben des Headers. Diese Reihenfolge stellt sicher, dass WAF-Regeln auf die endgültige Anforderung angewendet werden, die von Ihrem Back-End-Pool empfangen wird.
Angenommen, Sie verwenden die folgende Regel zur Headerumschreibung für den Header "Accept" : "text/html": Wenn der Wert des Headers "Accept" mit "text/html" übereinstimmt, soll der Wert in "image/png" umgeschrieben werden.
Wenn nur das Umschreiben von Headern konfiguriert ist, erfolgt die WAF-Auswertung bei "Accept" : "text/html". Wenn Sie jedoch das Umschreiben von URLs oder Hostheadern konfigurieren, wird die WAF-Auswertung bei "Accept" : "image/png" durchgeführt.
Vergleich von URL-Umschreibung und URL-Umleitung
Bei einer URL-Umschreibung wird die URL von Application Gateway umgeschrieben, bevor die Anforderung an das Back-End gesendet wird. Dadurch wird nicht geändert, was Benutzer*innen im Browser angezeigt wird, da die Änderungen für die Benutzer*innen im Hintergrund erfolgen.
Bei einer URL-Umleitung sendet Application Gateway eine Umleitungsantwort mit der neuen URL an den Client. Dazu muss der Client wiederum seine Anforderung erneut an die neue in der Umleitung bereitgestellte URL senden. Die URL, die der Benutzer im Browser sieht, wird durch die neue URL ersetzt.
Begrenzungen
- Das erneute Generieren wird nicht unterstützt, wenn das Anwendungsgateway so konfiguriert ist, dass die Anforderungen umgeleitet werden oder eine benutzerdefinierte Fehlerseite angezeigt wird.
- Anforderungsheadernamen können alphanumerische Zeichen und Bindestriche enthalten. Headernamen, die andere Zeichen enthalten, werden verworfen, wenn eine Anforderung an das Backend-Ziel gesendet wird.
- Wie in RFC 7230 festgelegt, können Antwort-Headernamen beliebige alphanumerischen Zeichen und Sonderzeichen beinhalten.
- Verbindungs- und Upgradeheader können nicht umgeschrieben werden.
- Das erneute Generieren wird für 4xx- und 5xx-Antworten nicht unterstützt, die direkt von Application Gateway generiert werden.