URL Rewrite Module 2.0 Configuration Reference (Konfigurationsreferenz für das URL-Umschreibungsmodul)

Artikel
04/12/2024

Dieser Abschnitt der Dokumentation bezieht sich auf die URL Rewrite Module Version 2.0 für IIS 7

In diesem Artikel finden Sie eine Übersicht über die Funktionalität von URL Rewrite Module 2.0 und erläutert die neuen Konfigurationskonzepte, die in dieser Version verwendet werden. Ausführliche Informationen zur URL Rewrite Module 1.1-Konfiguration finden Sie unter URL Rewrite Module Configuration Reference.

Inhaltsverzeichnis

Übersicht über die Funktionalität

Microsoft URL Rewrite Module 2.0 für IIS ist eine inkrementelle Version, die alle Features von Version 1.1 enthält und Unterstützung für Antwortheader und Inhaltsumschreibung hinzufügt. Das Modul wendet reguläre Ausdrücke oder Wild Karte s Muster auf die HTTP-Antwort an, um die Inhaltsteile basierend auf der neu geschriebenen Logik zu suchen und zu ersetzen, die durch ausgehende Neuschreibregeln ausgedrückt wird. Genauer gesagt kann das Modul für Folgendes verwendet werden:

Ersetzen Sie die urLs, die von einer Webanwendung im Antwort-HTML-Code generiert werden, durch eine benutzerfreundlichere und suchmaschinenfreundlichere Entsprechung.
die Links im HTML-Markup zu ändern, die von einer Webanwendung hinter einem Reverseproxy generiert werden.
Ändern Sie die vorhandenen und festlegen sie neue ANTWORT-HTTP-Header.
Beheben Sie den Inhalt einer beliebigen HTTP-Antwort, einschließlich JavaScript, CSS, RSS usw.

Warnung

Wenn Antwortheader oder der Antwortinhalt von einer Rewrite-Ausgangsregel geändert werden, sollte eine zusätzliche Vorsichtsmaßnahme ergriffen werden, um sicherzustellen, dass der Text, der in die Antwort eingefügt wird, keinen clientseitigen ausführbaren Code enthält, was zu websiteübergreifenden Scripting-Sicherheitsrisiken führen kann. Das ist besonders wichtig, wenn beim Umschreiben der Regel nicht vertrauenswürdige Daten verwendet werden, z. B. HTTP-Header oder die Abfragezeichenfolge, um die Zeichenfolge zu erstellen, die in die HTTP-Antwort eingefügt wird. In solchen Fällen sollte die Ersetzungszeichenfolge mit der HtmlEncode-Funktion codiert werden, z. B.:

<action type="Rewrite" value="{HtmlEncode:{HTTP_REFERER}}" />

Übersicht über ausgehende Regeln

Das Standard Konfigurationskonzept, das für das Umschreiben von Antworten verwendet wird, ist das Konzept einer ausgehenden Regel. Eine ausgehende Regel wird verwendet, um die Logik zum Vergleichen oder Abgleichen des Antwortinhalts auszudrücken und zu tun, wenn der Vergleich erfolgreich war.

Konzeptionell besteht eine ausgehende Regel aus den folgenden Teilen:

Vorbedingung – Die optionale Vorbedingung wird verwendet, um die Anforderungsmetadaten zu überprüfen, bevor eine Regelauswertung beginnt. Die Vorbedingung kann aus mehreren bedingten Überprüfungen auf Anforderungsmetadaten bestehen und kann verwendet werden, um Antworten herauszufiltern, die nicht umgeschrieben werden sollten, z. B. Bilder oder Videodateien.
Tagfilter – Die Tagfilter werden verwendet, um die Suche innerhalb der Antwort auf eine Reihe bekannter oder benutzerdefinierter Tags einzugrenzen. Bei Tagfiltern wird nur der Inhalt der angegebenen Tags mit dem Regelmuster abgeglichen, im Gegensatz zum Abgleichen des gesamten Antwortinhalts mit dem Muster.
Muster – Das Regelmuster wird verwendet, um entweder den regulären Ausdruck oder ein Wild Karte Muster anzugeben, das für die Suche innerhalb des Antwortinhalts verwendet wird.
Bedingungen – Die optionale Bedingungssammlung wird verwendet, um zusätzliche logische Vorgänge anzugeben, die ausgeführt werden sollen, wenn eine Mustervergleichung innerhalb des Antwortinhalts gefunden wurde. Innerhalb der Bedingungen können Sie nach bestimmten Werten von HTTP-Headern oder Servervariablen suchen.
Aktion – Die Aktion wird verwendet, um anzugeben, was zu tun ist, wenn die Musterüberstimmung gefunden wurde und alle Regelbedingungen erfolgreich ausgewertet wurden.

Regelausführung

Der Prozess der Ausführung ausgehender Regeln unterscheidet sich von dem, der für eingehende Regeln verwendet wird. Das eingehende Ruleset wird nur einmal pro Anforderung ausgewertet, da es sich bei der Eingabe nur um eine einzelne Anforderungs-URL-Zeichenfolge handelt. Ausgehende Regeln werden möglicherweise mehrmals pro Antwort ausgewertet, da sie an mehreren Stellen innerhalb von HTTP-Antwortinhalten angewendet wird. Wenn z. B. ein Regelsatz wie folgt vorhanden ist:

Regel 1: Gilt für <ein> Tag und <ein IMG-Tag>

Regel 2: Gilt für <ein> Tag

und die HTML-Antwort enthält dieses Markup:

<a href="/default.aspx"><img src="/logo.jpg" />Home Page</a>

Anschließend wertet URL Rewrite Module 2.0 Regel 1 für die Zeichenfolge "/default.aspx" aus. Wenn die Regel erfolgreich ausgeführt wurde, wird die Ausgabe von Regel 1 regel2 zugewiesen. Wenn Regel 2 erfolgreich ausgeführt wurde, wird die Ausgabe von Regel 2 verwendet, um den Inhalt des href-Attributs in dem <Tag> in der Antwort zu ersetzen.

Nach dieser URL rewrite Module 2.0 wird Rule1 mit der Zeichenfolge "/logo.jpg" ausgewertet. Wenn die Regel erfolgreich ausgeführt wurde, wird die Ausgabe verwendet, um den Inhalt des src-Attributs im <img-Tag> in der Antwort zu ersetzen.

Regelvererbung

Wenn Regeln auf mehreren Konfigurationsebenen definiert sind, wertet das URL-Neuschreibmodul den Regelsatz aus, der verteilte Regeln von übergeordneten Konfigurationsebenen sowie Regeln aus der aktuellen Konfigurationsstufe enthält. Die Auswertung erfolgt in einer Reihenfolge zwischen übergeordneten und untergeordneten Elementen. Dies bedeutet, dass die übergeordneten Regeln zuerst ausgewertet werden und die auf einer letzten untergeordneten Ebene definierten Regeln zuletzt ausgewertet werden.

Konfiguration ausgehender Regeln

Pre-conditions-Auflistung

Vorbedingungen werden verwendet, um zu überprüfen, ob eine Regel anhand eines Antwortinhalts ausgewertet werden soll. Die Vorbedingungsauflistung wird als benannte Auflistung im <Abschnitt "preConditions" definiert und kann eine oder mehrere Vorbedingungsprüfungen> enthalten. Die ausgehende Regel verweist auf die Vorbedingungsauflistung anhand des Namens.

Eine Vorbedingungsauflistung verfügt über ein Attribut namens LogicalGrouping , das steuert, wie Bedingungen ausgewertet werden. Eine Vorbedingungsauflistung wird als "true" ausgewertet, wenn:

Alle voreingestellten Bedingungen wurden auf "true" ausgewertet, vorausgesetzt, dass logicalGrouping="MatchAll" verwendet wurde.
Mindestens eine der Vorbedingungen wurde auf "true" ausgewertet, sofern logicalGrouping="MatchAny" verwendet wurde.

Eine Vorbedingung wird durch Angeben der folgenden Eigenschaften definiert:

Eingabezeichenfolge – Vorbedingungseingabe gibt an, welches Element als Eingabe für die Bedingungsauswertung verwendet werden soll. Die Vorbedingungseingabe ist eine beliebige Zeichenfolge, die Servervariablen und Backverweise auf vorherige Präbedingungsmuster enthalten kann.
Muster – Vorbedingungsmuster können entweder mithilfe der Syntax regulärer Ausdrücke oder mithilfe einer Wild Karte syntax angegeben werden. Der Typ des Musters, das in einer Vorbedingung verwendet werden soll, hängt vom Wert des musterSyntax-Flags ab, das für die Vorbedingungsauflistung definiert ist.

Darüber hinaus kann das Ergebnis der Vorbedingungsauswertung mithilfe des Negate-Attributs negiert werden.

Ein Beispiel für eine Vorbedingung, die überprüft, ob der Antwortinhaltstyp Text/HTML ist:

<preConditions>
    <preCondition name="IsHTML">
        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
    </preCondition>
</preConditions>

Kategorienfilter

Tagfilter werden verwendet, um die Suche innerhalb des Antwortinhalts auf eine Reihe bekannter oder benutzerdefinierter HTML-Tags einzugrenzen. Wenn eine Neuschreibregel Tagfilter verwendet, sucht url Rewrite Module 2.0 nach einem HTML-Tags, die im Tagfilter der Regel aufgelistet sind, und verwendet dann den Inhalt des URL-Attributs dieses Tags und wertet es anhand des Musters der Regel aus. Tagfilter werden im filterByTags-Attribut des <Übereinstimmungselements> einer ausgehenden Regel angegeben. Zum Beispiel:

<match filterByTags="A" pattern="^/(article\.aspx.*)" />

Wenn eine HTTP-Antwort ein Ankertag enthält, z. B.:

<a href="/article.aspx?id=1">link</a>

Anschließend wird das Neuschreibregelmuster anhand der Zeichenfolge "/article.aspx?id=1" ausgewertet.

Vordefinierte Tags

Das URL Rewrite Module 2.0 enthält eine Reihe vordefinierter Tags, die mit ausgehenden Regeln verwendet werden können. In der folgenden Tabelle sind alle vordefinierten Tags und Attribute aufgeführt, deren Werte als Eingabe für ausgehendes Regelmuster verwendet werden:

Tag	Attribute
Ein	href
Bereich	href
Basis	href
Form	action
Frame	src, longdesc
Head	profile
IFrame	src, longdesc
Abbildung	src, longdesc, usemap
Eingabe	src, usemap
Verknüpfung	href
Skript	src

Benutzerdefinierte Tags

Wenn das Umschreiben innerhalb eines Attributs eines Tags ausgeführt werden muss, das nicht in der vordefinierten Tags-Auflistung enthalten ist, kann eine benutzerdefinierte Tagauflistung verwendet werden, um den Tagnamen und das entsprechende Attribut anzugeben, das neu geschrieben werden muss. Benutzerdefinierte Tags-Auflistung wird als benannte Auflistung im <Abschnitt "customTags"> definiert. Ausgehende Regel verweist auf eine benutzerdefinierte Tags-Auflistung anhand des Namens.

Das folgende Beispiel zeigt eine Definition einer benutzerdefinierten Tags-Auflistung:

<customTags>
    <tags name="My Tags">
        <tag name="item" attribute="src" />
        <tag name="element" attribute="src" />
    </tags>
</customTags>

Auf diese sammlung benutzerdefinierter Tags kann aus einer ausgehenden Regel verwiesen werden, wie im folgenden Beispiel gezeigt:

<match filterByTags="A, CustomTags" customTags="My Tags" pattern="^/(article\.aspx.*)" />

Regelmuster

Ein Regelmuster wird verwendet, um anzugeben, mit welcher Regeleingabezeichenfolge abgeglichen werden soll. Die Regeleingabe unterscheidet sich je nach Regelkonfiguration:

Wenn die Regel Tagfilter verwendet, wird der Inhalt des zugeordneten Tags als Eingabe für den Musterabgleich übergeben.
Wenn die Regel keine Tagfilter verwendet, wird der gesamte Antwortinhalt als Eingabe für den Musterabgleich übergeben.

Das Muster wird innerhalb eines <Übereinstimmungselements> einer Neuschreibregel angegeben.

Vollständiger Antwortmusterabgleich

Wenn das Attribut "filterByTags" im Übereinstimmungselement der Regel nicht angegeben wird, wird das Muster auf den gesamten Antwortinhalt angewendet. Die Auswertung regulärer Ausdrucksmuster für den gesamten Antwortinhalt ist ein CPU-intensiver Vorgang und kann sich auf die Leistung der Webanwendung auswirken. Es gibt mehrere Optionen, um den Leistungsaufwand zu verringern, der durch den vollständigen Antwortmusterabgleich eingeführt wird:

Verwenden Sie das Zwischenspeichern des IIS-Benutzermodus, und legen Sie das Attribut "rewriteBeforeCache " des <Elements "outboundRules> " auf "true" fest:
```
<outboundRules rewriteBeforeCache="true">
```
Beachten Sie, dass diese Einstellung nicht verwendet werden sollte, wenn die Blockübertragungscodierung für Antworten verwendet wird.
Verwenden Sie das Vorkommen-Attribut des Übereinstimmungselements der Regel. Wenn Sie z. B. eine Regel verwenden, um einige HTML-Fragmente in das <Kopfelement> einzufügen, und diese Regel weist ein Muster auf, das nach dem schließenden Tag sucht – </head>, dann können Sie Vorkommen ="1" festlegen. Dadurch wird das Rewrite-Modul aufgefordert, die Suche nach der Antwort zu beenden Standard der der Antwort, nachdem das <Tag "/head>" gefunden wurde.
```
<match pattern="&lt;/head&gt;" occurrences="1" />
```

Regelmustersyntax

Die Regelmustersyntax kann mithilfe des PatternSyntax-Attributs einer Regel angegeben werden. Dieses Attribut kann auf eine der folgenden Optionen festgelegt werden:

ECMAScript – Perl-kompatible Reguläre Ausdruckssyntax (ECMAScript-Standardkonform) Dies ist eine Standardoption für jede Regel. Dies ist ein Beispiel für das Musterformat: "^([_0-9a-zA-Z-]+/)? (wp-.*)"

Wild Karte – Wild Karte Syntax, die im IIS-HTTP-Umleitungsmodul verwendet wird. Dies ist ein Beispiel für ein Muster in diesem Format: "/Scripts/*.js", wobei Sternchen ("*") "mit einer beliebigen Anzahl beliebiger Zeichen übereinstimmen und in einem Rückverweis erfassen" bedeutet. Beachten Sie, dass der Mustertyp "wild Karte" nicht verwendet werden kann, wenn die Regel keine Tagfilter enthält.

ExactMatch : Die genaue Zeichenfolgensuche wird innerhalb der Eingabezeichenfolge ausgeführt.

Der Bereich des PatternSyntax-Attributs ist pro Regel, d. h. er gilt für das Muster der aktuellen Regel und für alle Muster, die in Bedingungen dieser Regel verwendet werden.

Regelmustereigenschaften

Das Muster kann mithilfe des "negate "-Attributs des <Match-Elements> negiert werden. Wenn dieses Attribut verwendet wird, wird die Regelaktion nur ausgeführt, wenn die Eingabezeichenfolge NICHT mit dem angegebenen Muster übereinstimmt.

Standardmäßig wird die Übereinstimmung zwischen Groß- und Kleinschreibung nicht beachtet. Um die Groß-/Kleinschreibung zu aktivieren, können Sie das ignoreCase-Attribut des <Übereinstimmungselements> der Regel verwenden.

Regelbedingungen

Regelbedingungen ermöglichen das Definieren zusätzlicher Logik für die Regelauswertung, die auf anderen Eingaben als nur einer aktuellen Eingabezeichenfolge basieren kann. Jede Regel kann null oder mehr Bedingungen aufweisen. Regelbedingungen werden ausgewertet, nachdem die Regelmustervergleich erfolgreich war.

Bedingungen werden in einer <Bedingungsauflistung> einer Neuschreibregel definiert. Diese Auflistung verfügt über ein Attribut namens LogicalGrouping , das steuert, wie Bedingungen ausgewertet werden. Wenn eine Regel Bedingungen aufweist, wird die Regelaktion nur ausgeführt, wenn das Regelmuster übereinstimmen und:

Alle Bedingungen wurden auf "true" ausgewertet, vorausgesetzt, dass logicalGrouping="MatchAll" verwendet wurde.
Mindestens eine der Bedingungen wurde auf "true" ausgewertet, vorausgesetzt, dass logicalGrouping="MatchAny" verwendet wurde.

Eine Bedingung wird durch Angeben der folgenden Eigenschaften definiert:

Eingabezeichenfolge: Bedingungseingabe gibt an, welches Element als Eingabe für die Bedingungsauswertung verwendet werden soll. Bedingungseingabe ist eine beliebige Zeichenfolge, die Servervariablen und Back-References auf vorherige Bedingungsmuster und/oder Regelmuster enthalten kann.
Muster – Ein Muster, nach dem in der Bedingungseingabe gesucht werden soll. Ein Muster kann mithilfe einer Syntax für reguläre Ausdrücke oder mithilfe einer Wild Karte syntax angegeben werden. Der Typ des musters, das in einer Bedingung verwendet werden soll, hängt vom Wert des musterSyntax-Flags ab , das für die Regel definiert ist, zu der diese Bedingung gehört. Dieser Bedingungstyp weist zwei verwandte Attribute auf, die den Musterabgleich steuern:
- pattern – Verwenden Sie dieses Attribut, um das tatsächliche Muster anzugeben.
- ignoreCase – Verwenden Sie dieses Attribut, um zu steuern, ob der Musterabgleich für die Bedingung die Groß-/Kleinschreibung beachtet oder die Groß-/Kleinschreibung nicht beachtet werden soll.

Regelaktion

Eine Neuschreibregelaktion wird ausgeführt, wenn die Eingabezeichenfolge dem Regelmuster entspricht und die Bedingungsauswertung erfolgreich war (je nach Regelkonfiguration, entweder alle Bedingungen, die übereinstimmen, oder eine oder mehrere der bedingungen übereinstimmen). Es sind zwei Arten von Aktionen verfügbar, und das Attribut "type" des <Aktionskonfigurationselements> kann verwendet werden, um anzugeben, welche Aktion die Regel ausführen muss. In den folgenden Abschnitten werden verschiedene Aktionstypen und die Konfigurationsoptionen für bestimmte Aktionstypen beschrieben.

Aktion neu schreiben

Die Aktion "Neu schreiben" ersetzt die aktuelle Regeleingabezeichenfolge durch eine Ersetzungszeichenfolge. Die Ersetzungszeichenfolge wird innerhalb des Wertattributes des <Aktionselements> der Regel angegeben. Die Ersetzungszeichenfolge ist eine freie Formularzeichenfolge, die Folgendes enthalten kann:

Zurückverweise auf die Bedingungs- und Regelmuster. (Weitere Informationen finden Sie im Abschnitt zur Verwendung von Back-References.)
Die Servervariablen. (Weitere Informationen finden Sie im Abschnitt zur Verwendung von Servervariablen.)

Keine Aktion

Keine Aktion wird verwendet, um anzugeben, dass keine Aktion ausgeführt werden soll.

Zugreifen auf Antwortheader aus Rewrite-Regeln

Der Inhalt eines beliebigen Antwort-HTTP-Headers kann aus einer Umschreibregel abgerufen werden, indem die gleiche Syntax verwendet wird wie für den Zugriff auf Servervariablen, aber mit einer speziellen Benennungskonvention. Wenn eine Servervariable mit "RESPONSE_" beginnt, speichert sie den Inhalt eines HTTP-Antwortheaders, dessen Name mithilfe der folgenden Benennungskonvention bestimmt wird:

Alle Unterstrichsymbole ("_") im Namen werden in Gedankenstrichsymbole ("-") konvertiert.
Das Präfix "RESPONSE_" wird entfernt.

Beispielsweise wird die folgende Vorbedingung verwendet, um den Inhalt des Inhaltstypheaders auszuwerten:

<preCondition name="IsHTML">
    <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
</preCondition>

Festlegen von Anforderungsheadern und Servervariablen

Regeln für eingehende Neuschreibung in URL Rewrite Module 2.0 können verwendet werden, um Anforderungsheader und Servervariablen festzulegen.

Liste zulässiger Servervariablen

Globale Umschreibregeln können zum Festlegen von Anforderungsheadern und Servervariablen sowie zum Überschreiben vorhandener Regeln verwendet werden. Verteilte Neuschreibregeln können nur die Anforderungsheader und Servervariablen festlegen/überschreiben, die in der Liste zulässiger Servervariables für Servervariables <>definiert sind. Wenn eine verteilte Rewrite-Regel versucht, eine Servervariable oder einen HTTP-Header festzulegen, der nicht in der <allowedServerVariables-Auflistung> aufgeführt ist, wird ein Laufzeitfehler vom URL Rewrite Module generiert. Die <allowedServerVariables-Auflistung> wird standardmäßig in der Datei "applicationHost.config" gespeichert und kann nur von einem IIS-Serveradministrator geändert werden.

Verwenden von Regeln zum Schreiben eingehender Rewrite-Regeln zum Festlegen von Anforderungsheadern und Servervariablen

Ein Regelelement <serverVariables> wird verwendet, um eine Sammlung von Servervariablen und http-Headern zu definieren, die festgelegt werden sollen. Diese werden nur festgelegt, wenn das Regelmuster übereinstimmen und die Bedingungsauswertung erfolgreich war (abhängig von der Regelkonfiguration, entweder alle Bedingungen, die übereinstimmen, oder eine oder mehrere der bedingungen übereinstimmen). Jedes Element in der <serverVariables-Auflistung> besteht aus den folgenden Elementen:

Name – gibt den Namen der festzulegenden Servervariable an.
Wert - gibt den Wert der Servervariable an. Der Wert ist eine freie Formularzeichenfolge, die Folgendes enthalten kann:
- Zurückverweise auf die Bedingungs- und Regelmuster. (Weitere Informationen finden Sie im Abschnitt zur Verwendung von Back-References.)
- Die Servervariablen. (Weitere Informationen finden Sie im Abschnitt zur Verwendung von Servervariablen.)
Replace flag - gibt an, ob der Wert der Servervariable überschrieben werden soll, wenn sie bereits vorhanden ist. Standardmäßig ist die Ersetzungsfunktion aktiviert.

Die folgende Beispielregel schreibt die angeforderte URL neu und legt die Servervariable auch mit dem Namen X_REQUESTED_URL_PATH fest:

<rule name="Rewrite to index.php" stopProcessing="true">
    <match url="(.*)\.htm$" />
    <serverVariables>
        <set name="X_REQUESTED_URL_PATH" value="{R:1}" />
    </serverVariables>
    <action type="Rewrite" url="index.php?path={R:1}" />
</rule>

Hinweis: Damit das obige Beispiel funktioniert, ist es erforderlich, der allowedServerVariables-Auflistung> X_REQUESTED_URL_PATH <hinzuzufügen:

<rewrite>
    <allowedServerVariables>
        <add name="X_REQUESTED_URL_PATH" />
    </allowedServerVariables>
</rewrite>

Hinweis zu Anforderungsheadern

Die Anforderungsheader werden mit demselben Mechanismus wie für Servervariablen festgelegt, jedoch mit einer speziellen Benennungskonvention. Wenn ein Servervariables-Name in der <serverVariables-Auflistung> mit "HTTP_" beginnt, führt dies zu einem HTTP-Anforderungsheader, der gemäß der folgenden Benennungskonvention festgelegt wird:

Alle Unterstrichsymbole ("_") im Namen werden in Gedankenstrichsymbole ("-") konvertiert.
Alle Buchstaben werden in Kleinbuchstaben konvertiert.
Das Präfix "HTTP_" wird entfernt.

Die folgende Konfiguration wird beispielsweise verwendet, um den benutzerdefinierten x-original-Hostheader für die Anforderung zu festlegen:

<set name="HTTP_X_ORIGINAL_HOST" value="{HTTP_HOST}" />

Festlegen von Antwortheadern

Ausgehende Rewrite-Regeln in URL Rewrite Module 2.0 können verwendet werden, um neue oder vorhandene Antwort-HTTP-Header festzulegen. Auf die ANTWORT-HTTP-Header wird innerhalb der ausgehenden Regeln zugegriffen, indem die gleiche Syntax wie für Servervariablen verwendet wird und die Benennungskonvention verwendet wird, wie unter "Zugreifen auf Antwortheader" aus "Rewrite Rules" beschrieben.

Wenn das serverVariable-Attribut des <Übereinstimmungselements> einer ausgehenden Rewrite-Regel einen Wert aufweist, gibt es an, dass diese Neuschreibregel für den Inhalt des entsprechenden Antwortheaders ausgeführt wird. Die folgende Regel legt beispielsweise den Antwortheader "x-custom-header" fest:

<outboundRules>
    <rule name="Set Custom Header">
        <match serverVariable="RESPONSE_X_Custom_Header" pattern="^$" />
        <action type="Rewrite" value="Something" />
    </rule>
</outboundRules>

Das Muster der Umschreibregel wird auf den Inhalt des angegebenen Antwortheaders angewendet, und wenn das Muster und optionale Bedingungen der Regel erfolgreich ausgewertet werden, wird der Wert dieses Antwortheaders neu geschrieben.

Die Muster für reguläre Ausdrücke und der einfache Zugriff auf vorhandene Anforderungs- und Antwortheader in einer Umschreibregel bieten eine Menge Flexibilität beim Definieren einer Logik zum Umschreiben von Antwort-HTTP-Headern. Die folgende Umschreibregel kann beispielsweise verwendet werden, um den Inhalt des Headers "Location" in Umleitungsantworten zu ändern:

<outboundRules>
    <!-- This rule changes the domain in the HTTP location header for redirection responses -->
    <rule name="Change Location Header">
        <match serverVariable="RESPONSE_LOCATION" pattern="^http://[^/]+/(.*)" />
        <conditions>
            <add input="{RESPONSE_STATUS}" pattern="^301" />
        </conditions>
        <action type="Rewrite" value="http://{HTTP_HOST}/{R:1}"/>
    </rule>
</outboundRules>

Verwenden von Back-References in Rewrite Rules

Teile von Regeln oder Bedingungeneingaben können in Backverweise erfasst werden. Diese können dann zum Erstellen von Ersetzungs-URLs innerhalb von Regelaktionen oder zum Erstellen von Eingabezeichenfolgen für Regelbedingungen verwendet werden.

Back-References werden auf unterschiedliche Weise generiert, je nachdem, welche Art von Mustersyntax für die Regel verwendet wird. Wenn die ECMAScript-Mustersyntax verwendet wird, kann ein Rückverweis erstellt werden, indem Klammern um den Teil des Musters platziert werden, der den Backverweis erfassen muss. Beispielsweise erfasst das Muster ([0-9]+)/([a-z]+).html 07 und Artikel in Back-References aus dieser Zeichenfolge: 07/article.html. Wenn die Mustersyntax "Wild Karte" verwendet wird, werden die Rückverweise immer erstellt, wenn ein Sternchen (*) im Muster verwendet wird.

Die Verwendung von Rückbezügen ist unabhängig davon, welche Mustersyntax zum Erfassen verwendet wurde, identisch. Back-References können an den folgenden Speicherorten innerhalb von Rewrite-Regeln verwendet werden:

In Bedingungseingabezeichenfolge
In Regelaktion, insbesondere:
- URL-Attribut der Rewrite- und Umleitungsaktion in eingehenden Regeln
- Value-Attribut der Rewrite-Aktion in ausgehenden Regeln
- statusLine und responseLine der CustomResponse-Aktion
In key parameter to the rewrite map

Rückverweise auf Bedingungsmuster werden durch {C:N} identifiziert, wobei N von 0 bis 9 liegt; Back-References auf Regelmuster werden durch {R:N} identifiziert, wobei N von 0 bis 9 liegt. Beachten Sie, dass für beide Typen von Back-References{ R:0} und {C:0} die übereinstimmende Zeichenfolge enthalten wird.

Beispiel in diesem Muster:

^(www\.)(.*)$

Für die Zeichenfolge: www.foo.com Die Rückverweise werden wie folgt indiziert:

{C:0} - www.foo.com
{C:1} - www.
{C:2} - foo.com

Nachverfolgen von Erfassungsgruppen über Bedingungen hinweg

Standardmäßig können Sie in einer Regelaktion die Rückverweise auf das Regelmuster und die letzte übereinstimmende Bedingung dieser Regel verwenden. In dieser Regel beispielsweise:

<rule name="Back-references with trackAllCaptures set to false">
 <match url="^article\.aspx" >
 <conditions>
    <add input="{QUERY_STRING}" pattern="p1=([0-9]+)" />
    <add input="{QUERY_STRING}" pattern="p2=([a-z]+)" />  
 </conditions>
 <action type="Rewrite" url="article.aspx/{C:1}" /> <!-- rewrite action uses back-references to the last matched condition -->
</rule>

Der Back-Reference {C:1} enthält immer den Wert der Aufnahmegruppe aus der zweiten Bedingung, bei der es sich um den Wert des Abfragezeichenfolgenparameters p2 handeln wird. Der Wert von p1 ist nicht als Back-Reference verfügbar.

In URL Rewrite Module 2.0 ist es möglich, die Indizierung von Aufnahmegruppen zu ändern. Wenn die Einstellung "trackAllCaptures" für die <Bedingungsauflistung> aktiviert wird, werden die Erfassungsgruppen alle übereinstimmenden Bedingungen über die Backverweise verfügbar gemacht. In dieser Regel beispielsweise:

<rule name="Back-references with trackAllCaptures set to true">
 <match url="^article\.aspx" >
 <conditions trackAllCaptures="true">
    <add input="{QUERY_STRING}" pattern="p1=([0-9]+)" />
    <add input="{QUERY_STRING}" pattern="p2=([a-z]+)" />  
 </conditions>
 <action type="Rewrite" url="article.aspx/{C:1}/{C:2}" /> <!-- rewrite action uses back-references to both conditions -->
</rule>

Der Back-Reference {C:1} enthält den Wert der Aufnahmegruppe aus der ersten Bedingung, und der Back-Reference {C:2} enthält den Wert der Aufnahmegruppe aus der zweiten Bedingung.

Wenn "trackAllCaptures" auf "true" festgelegt ist, werden die Rückverweise der Bedingungserfassung durch {C:N} identifiziert, wobei N zwischen 0 und der Gesamtanzahl der Aufnahmegruppen für alle Bedingungen der Regel liegt. {C:0} enthält die gesamte übereinstimmene Zeichenfolge aus der ersten übereinstimmenen Bedingung. Beispiel für diese beiden Bedingungen:

<conditions trackAllCaptures="true">
    <add input="{REQUEST_URI}" pattern="^/([a-zA-Z]+)/([0-9]+)/$" />
    <add input="{QUERY_STRING}" pattern="p2=([a-z]+)" />  
 </conditions>

Wenn {REQUEST_URI} "/article/23/" enthält und {QUERY_STRING} "p1=123&p2=abc" enthält, werden die Bedingungsrückverweise wie folgt indiziert:

{C:0} - "/article/23/"
{C:1} - "Artikel"
{C:2} - "23"
{C:3} - "abc"

Protokollierung von umgeschriebenen URLs in IIS-Protokolle

Eine verteilte Rewrite-Regel kann so konfiguriert werden, dass neu geschriebene URLs in den IIS-Protokolldateien protokolliert werden, anstatt die ursprünglichen URLs zu protokollieren, die vom HTTP-Client angefordert werden. Verwenden Sie zum Aktivieren der Protokollierung neu geschriebener URLs das logRewrittenUrl-Attribut des Aktionselements <> der Regel, z. B.:

<rule name="set server variables">
    <match url="^article/(\d+)$" />
    <action type="Rewrite" url="article.aspx?id={R:1}" logRewrittenUrl="true" />
</rule>

Freigeben über