RewriteRule-Flags

Einführung ¶

Das Verhalten einer RewriteRule kann durch ein oder mehrere Flags modifiziert werden. Flags werden in eckigen Klammern am Ende der Regel angegeben, und mehrere Flags werden durch Kommas getrennt.

RewriteRule pattern target [Flag1,Flag2,Flag3]

Jedes Flag hat (mit wenigen Ausnahmen) eine Kurzform, wie CO, sowie eine Langform, wie cookie. Obwohl es am häufigsten ist, die Kurzform zu verwenden, wird empfohlen, sich mit der Langform vertraut zu machen, damit Sie sich merken können, was jedes Flag bewirken soll. Einige Flags akzeptieren ein oder mehrere Argumente. Flags unterscheiden nicht zwischen Groß- und Kleinschreibung.

Flags, die mit der Anfrage verknüpfte Metadaten ändern (T=, H=, E=), haben im Verzeichniskontext und htaccess-Kontext keine Wirkung, wenn eine Ersetzung (außer '-') während derselben Runde der Umschreibungsverarbeitung durchgeführt wird.

Hier werden alle verfügbaren Flags vorgestellt, zusammen mit einem Beispiel, wie Sie diese verwenden könnten.

B (Rückreferenzen maskieren) ¶

Das [B]-Flag weist RewriteRule an, nicht-alphanumerische Zeichen vor der Anwendung der Transformation zu maskieren.

mod_rewrite muss URLs demaskieren, bevor sie zugeordnet werden, sodass Rückreferenzen zum Zeitpunkt ihrer Anwendung demaskiert sind. Mit dem B-Flag werden nicht-alphanumerische Zeichen in Rückreferenzen maskiert. Betrachten Sie beispielsweise die folgende Regel:

Für eine ähnliche Maskierung von Server-Variablen siehe die "escape"-Zuordnungsfunktion

RewriteRule "^search/(.*)$" "/search.php?term=$1"

Bei einem Suchbegriff von 'x & y/z' kodiert ein Browser diesen als 'x%20%26%20y%2Fz', sodass die Anfrage 'search/x%20%26%20y%2Fz' lautet. Ohne das B-Flag wird diese Rewrite-Regel auf 'search.php?term=x & y/z' abgebildet, was keine gültige URL ist und daher als search.php?term=x%20&y%2Fz= kodiert würde, was nicht beabsichtigt war.

Mit gesetztem B-Flag bei derselben Regel werden die Parameter erneut kodiert, bevor sie an die Ausgabe-URL übergeben werden, was zu einer korrekten Zuordnung zu /search.php?term=x%20%26%20y%2Fz führt.

RewriteRule "^search/(.*)$" "/search.php?term=$1" [B,PT]

Beachten Sie, dass Sie möglicherweise auch AllowEncodedSlashes auf On setzen müssen, damit dieses spezielle Beispiel funktioniert, da httpd keine kodierten Schrägstriche in URLs zulässt und bei deren Auftreten einen 404-Fehler zurückgibt.

Diese Maskierung ist besonders notwendig in einer Proxy-Situation, wenn das Backend bei einer nicht-maskierten URL Probleme haben könnte.

Eine Alternative zu diesem Flag ist die Verwendung einer RewriteCond, die gegen %{THE_REQUEST} prüft, welche Strings in kodierter Form erfasst.

Ab Version 2.4.26 können Sie die Maskierung auf bestimmte Zeichen in Rückreferenzen beschränken, indem Sie diese auflisten: [B=#?;]. Hinweis: Das Leerzeichen kann in der Liste der zu maskierenden Zeichen verwendet werden, aber Sie müssen das gesamte dritte Argument der RewriteRule in Anführungszeichen setzen und das Leerzeichen darf nicht das letzte Zeichen in der Liste sein.

# Leerzeichen und Fragezeichen maskieren. Die Anführungszeichen um das letzte Argument
# sind erforderlich, wenn ein Leerzeichen enthalten ist.
RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B= ?]"

Um die auf diese Weise maskierten Zeichen einzuschränken, siehe #flag_bne und #flag_bctls

BNP|backrefnoplus (Leerzeichen nicht zu + maskieren) ¶

Das [BNP]-Flag weist RewriteRule an, das Leerzeichen in einer Rückreferenz zu %20 statt zu '+' zu maskieren. Nützlich, wenn die Rückreferenz im Pfadteil statt im Query-String verwendet wird.

# Leerzeichen im Pfad zu %20 maskieren statt zu +, wie es bei Formularübermittlungen
# über den Query-String verwendet wird
RewriteRule "^search/(.*)$" "/search.php/$1" "[B,BNP]"

Dieses Flag ist ab Version 2.4.26 verfügbar.

BCTLS ¶

Das [BCTLS]-Flag ähnelt dem [B]-Flag, maskiert aber nur Steuerzeichen und das Leerzeichen. Dies ist dieselbe Menge von Zeichen, die abgelehnt werden, wenn sie unkodiert in den Query-String kopiert werden.

# Steuerzeichen und Leerzeichen maskieren
RewriteRule "^search/(.*)$" "/search.php/$1" "[BCTLS]"

Dieses Flag ist ab Version 2.5.1 verfügbar.

BNE ¶

Die Liste der Zeichen in [BNE=...] wird als Ausnahmen von den Zeichen der [B]- oder [BCTLS]-Flags behandelt. Die aufgelisteten Zeichen werden nicht maskiert.

# Standardzeichen maskieren, aber / beibehalten
RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B,BNE=/]"

Dieses Flag ist ab Version 2.5.1 verfügbar.

C|chain ¶

Das [C]- oder [chain]-Flag zeigt an, dass die RewriteRule mit der nächsten Regel verkettet ist. Wenn die Regel übereinstimmt, wird sie wie gewohnt verarbeitet und die Kontrolle geht an die nächste Regel über. Wenn sie jedoch nicht übereinstimmt, werden die nächste Regel und alle weiteren verketteten Regeln übersprungen.

CO|cookie ¶

Das [CO]- oder [cookie]-Flag ermöglicht es Ihnen, ein Cookie zu setzen, wenn eine bestimmte RewriteRule übereinstimmt. Das Argument besteht aus drei erforderlichen und fünf optionalen Feldern.

Die vollständige Syntax für das Flag einschließlich aller Attribute lautet wie folgt:

Wenn ein literales ':'-Zeichen in einem der Cookie-Felder benötigt wird, steht eine alternative Syntax zur Verfügung. Um die alternative Syntax zu verwenden, sollte der Cookie-"Name" mit einem ';'-Zeichen eingeleitet werden, und die Feldtrenner sollten als ';' angegeben werden.

Sie müssen einen Namen, einen Wert und eine Domain angeben, damit das Cookie gesetzt wird.

Domain

Die Domain, für die das Cookie gültig sein soll. Dies kann ein Hostname sein, wie www.example.com, oder eine Domain, wie .example.com. Sie muss aus mindestens zwei durch einen Punkt getrennten Teilen bestehen. Das heißt, sie kann nicht einfach nur .com oder .net sein. Cookies dieser Art werden durch das Cookie-Sicherheitsmodell verboten.

Sie können optional auch die folgenden Werte setzen:

Lebensdauer

Die Zeit, für die das Cookie bestehen bleibt, in Minuten.

Ein Wert von 0 bedeutet, dass das Cookie nur für die aktuelle Browser-Sitzung bestehen bleibt. Dies ist der Standardwert, wenn keiner angegeben wird.

Ein negativer Wert bewirkt, dass das Cookie im Browser gelöscht wird.

Pfad

Der Pfad auf der aktuellen Website, für den das Cookie gültig ist, wie /customers/ oder /files/download/.

Standardmäßig ist dies auf / gesetzt - also die gesamte Website.

Secure

Wenn auf secure, true oder 1 gesetzt, wird das Cookie nur über sichere (https-)Verbindungen übertragen.

httponly

Wenn auf HttpOnly, true oder 1 gesetzt, wird das Cookie mit dem HttpOnly-Flag versehen, was bedeutet, dass das Cookie für JavaScript-Code in Browsern, die diese Funktion unterstützen, nicht zugänglich ist.

samesite

Wenn auf etwas anderes als false oder 0 gesetzt, wird das SameSite-Attribut auf den angegebenen Wert gesetzt. Typische Werte sind None, Lax und Strict. Verfügbar ab Version 2.5.1.

Betrachten Sie dieses Beispiel:

RewriteEngine On
RewriteRule   "^/index\.html"   "-" [CO=frontdoor:yes:.example.com:1440:/]

In diesem Beispiel schreibt die Regel die Anfrage nicht um. Das "-"-Umschreibungsziel weist mod_rewrite an, die Anfrage unverändert weiterzuleiten. Stattdessen setzt sie ein Cookie namens 'frontdoor' auf den Wert 'yes'. Das Cookie ist für jeden Host in der .example.com-Domain gültig. Es läuft in 1440 Minuten (24 Stunden) ab und wird für alle URIs zurückgegeben.

DPI|discardpath ¶

Das DPI-Flag bewirkt, dass der PATH_INFO-Teil des umgeschriebenen URI verworfen wird.

Dieses Flag ist ab Version 2.2.12 verfügbar.

Im Verzeichniskontext wird der URI, gegen den jede RewriteRule prüft, aus der Verkettung der aktuellen Werte von URI und PATH_INFO gebildet.

Der aktuelle URI kann der ursprünglich vom Client angeforderte URI sein, das Ergebnis einer vorherigen Runde der mod_rewrite-Verarbeitung oder das Ergebnis einer früheren Regel in der aktuellen Runde der mod_rewrite-Verarbeitung.

Im Gegensatz dazu spiegelt der PATH_INFO, der vor jeder Regel an den URI angehängt wird, nur den Wert von PATH_INFO vor dieser Runde der mod_rewrite-Verarbeitung wider. Wenn daher große Teile des URI in einer Ersetzung in mehreren RewriteRule-Direktiven abgeglichen und kopiert werden, ohne zu berücksichtigen, welche Teile des URI vom aktuellen PATH_INFO stammen, kann der endgültige URI mehrere Kopien von PATH_INFO enthalten.

Verwenden Sie dieses Flag bei jeder Ersetzung, bei der der PATH_INFO, der aus der vorherigen Zuordnung dieser Anfrage zum Dateisystem resultierte, nicht von Interesse ist. Dieses Flag vergisst dauerhaft den PATH_INFO, der vor dieser Runde der mod_rewrite-Verarbeitung festgelegt wurde. PATH_INFO wird erst neu berechnet, wenn die aktuelle Runde der mod_rewrite-Verarbeitung abgeschlossen ist. Nachfolgende Regeln während dieser Runde der Verarbeitung sehen nur das direkte Ergebnis der Ersetzungen, ohne angehängten PATH_INFO.

E|env ¶

Mit dem [E]- oder [env]-Flag können Sie den Wert einer Umgebungsvariable setzen. Beachten Sie, dass einige Umgebungsvariablen nach der Ausführung der Regel gesetzt werden können, wodurch das von Ihnen Gesetzte überschrieben wird. Siehe das Dokument zu Umgebungsvariablen für weitere Details zur Funktionsweise von Umgebungsvariablen.

Die vollständige Syntax für dieses Flag lautet:

[E=VAR:VAL]
[E=!VAR]

VAL kann Rückreferenzen ($N oder %N) enthalten, die expandiert werden.

In der Kurzform

können Sie die Umgebungsvariable namens VAR auf einen leeren Wert setzen.

Die Form

ermöglicht es, eine zuvor gesetzte Umgebungsvariable namens VAR zu löschen.

Umgebungsvariablen können dann in verschiedenen Kontexten verwendet werden, einschließlich CGI-Programmen, anderen RewriteRule-Direktiven oder CustomLog-Direktiven.

Das folgende Beispiel setzt eine Umgebungsvariable namens 'image' auf den Wert '1', wenn der angeforderte URI eine Bilddatei ist. Dann wird diese Umgebungsvariable verwendet, um diese Anfragen aus dem Zugriffsprotokoll auszuschließen.

RewriteRule "\.(png|gif|jpg)$"   "-" [E=image:1]
CustomLog   "logs/access_log"    combined env=!image

Beachten Sie, dass derselbe Effekt mit SetEnvIf erzielt werden kann. Diese Technik wird als Beispiel angeboten, nicht als Empfehlung.

END ¶

Die Verwendung des [END]-Flags beendet nicht nur die aktuelle Runde der Umschreibungsverarbeitung (wie [L]), sondern verhindert auch jede nachfolgende Umschreibungsverarbeitung im Verzeichniskontext (htaccess).

Dies gilt nicht für neue Anfragen, die aus externen Umleitungen resultieren.

F|forbidden ¶

Die Verwendung des [F]-Flags bewirkt, dass der Server einen 403-Forbidden-Statuscode an den Client zurückgibt. Obwohl dasselbe Verhalten mit der Deny-Direktive erreicht werden kann, ermöglicht dies mehr Flexibilität bei der Zuweisung eines Forbidden-Status.

Die folgende Regel verbietet das Herunterladen von .exe-Dateien von Ihrem Server.

RewriteRule "\.exe"   "-" [F]

Dieses Beispiel verwendet die "-"-Syntax für das Umschreibungsziel, was bedeutet, dass der angeforderte URI nicht geändert wird. Es gibt keinen Grund, zu einem anderen URI umzuschreiben, wenn Sie die Anfrage verweigern möchten.

Bei der Verwendung von [F] wird ein [L] impliziert - das heißt, die Antwort wird sofort zurückgegeben und keine weiteren Regeln werden ausgewertet.

G|gone ¶

Das [G]-Flag zwingt den Server, einen 410-Gone-Status mit der Antwort zurückzugeben. Dies zeigt an, dass eine Ressource früher verfügbar war, aber nicht mehr verfügbar ist.

Wie beim [F]-Flag verwenden Sie typischerweise die "-"-Syntax für das Umschreibungsziel, wenn Sie das [G]-Flag verwenden:

RewriteRule "oldproduct"   "-" [G,NC]

Bei der Verwendung von [G] wird ein [L] impliziert - das heißt, die Antwort wird sofort zurückgegeben und keine weiteren Regeln werden ausgewertet.

H|handler ¶

Erzwingt, dass die resultierende Anfrage mit dem angegebenen Handler behandelt wird. Beispielsweise könnte man dies verwenden, um alle Dateien ohne Dateiendung vom PHP-Handler parsen zu lassen:

RewriteRule "!\."  "-" [H=application/x-httpd-php]

Der obige reguläre Ausdruck - !\. - stimmt mit jeder Anfrage überein, die kein literales .-Zeichen enthält.

Dies kann auch verwendet werden, um den Handler basierend auf bestimmten Bedingungen zu erzwingen. Beispielsweise ermöglicht der folgende Ausschnitt, der im Server-Kontext verwendet wird, dass .php-Dateien von mod_php angezeigt werden, wenn sie mit der .phps-Erweiterung angefordert werden:

RewriteRule "^(/source/.+\.php)s$" "$1" [H=application/x-httpd-php-source]

Der obige reguläre Ausdruck - ^(/source/.+\.php)s$ - stimmt mit jeder Anfrage überein, die mit /source/ beginnt, gefolgt von einem oder mehreren Zeichen, gefolgt von .phps. Die Rückreferenz $1 verweist auf die erfasste Übereinstimmung innerhalb der Klammern des regulären Ausdrucks.

L|last ¶

Das [L]-Flag bewirkt, dass mod_rewrite die Verarbeitung des Regelsatzes stoppt. In den meisten Kontexten bedeutet dies, dass bei Übereinstimmung der Regel keine weiteren Regeln verarbeitet werden. Dies entspricht dem last-Befehl in Perl oder dem break-Befehl in C. Verwenden Sie dieses Flag, um anzuzeigen, dass die aktuelle Regel sofort angewendet werden soll, ohne weitere Regeln zu berücksichtigen.

Wenn Sie RewriteRule in .htaccess-Dateien oder in <Directory>-Abschnitten verwenden, ist es wichtig, ein gewisses Verständnis dafür zu haben, wie die Regeln verarbeitet werden. Die vereinfachte Form davon ist, dass nach der Verarbeitung der Regeln die umgeschriebene Anfrage an die URL-Parsing-Engine zurückgegeben wird. Es ist möglich, dass bei der Verarbeitung der umgeschriebenen Anfrage die .htaccess-Datei oder der <Directory>-Abschnitt erneut angetroffen wird und der Regelsatz von Anfang an erneut durchlaufen wird. Am häufigsten geschieht dies, wenn eine der Regeln eine Umleitung auslöst - entweder intern oder extern - wodurch der Anfrageprozess von vorne beginnt.

Es ist daher wichtig, wenn Sie RewriteRule-Direktiven in einem dieser Kontexte verwenden, dass Sie explizite Maßnahmen ergreifen, um Regelschleifen zu vermeiden, und sich nicht ausschließlich auf das [L]-Flag verlassen, um die Ausführung einer Reihe von Regeln zu beenden, wie unten gezeigt.

Ein alternatives Flag, [END], kann verwendet werden, um nicht nur die aktuelle Runde der Umschreibungsverarbeitung zu beenden, sondern auch jede nachfolgende Umschreibungsverarbeitung im Verzeichniskontext (htaccess) zu verhindern. Dies gilt nicht für neue Anfragen, die aus externen Umleitungen resultieren.

Das hier gegebene Beispiel schreibt jede Anfrage auf index.php um und gibt die ursprüngliche Anfrage als Query-String-Argument an index.php weiter. Die RewriteCond stellt jedoch sicher, dass die RewriteRule übersprungen wird, wenn die Anfrage bereits für index.php bestimmt ist.

RewriteBase "/"
RewriteCond "%{REQUEST_URI}" !=/index.php
RewriteRule "^(.*)"          "/index.php?req=$1" [L,PT]

N|next ¶

Das [N]-Flag bewirkt, dass der Regelsatz von oben neu gestartet wird, wobei das bisherige Ergebnis des Regelsatzes als Ausgangspunkt verwendet wird. Verwenden Sie es mit äußerster Vorsicht, da es zu Schleifen führen kann.

Das [Next]-Flag könnte beispielsweise verwendet werden, wenn Sie einen bestimmten String oder Buchstaben wiederholt in einer Anfrage ersetzen möchten. Das hier gezeigte Beispiel ersetzt A überall in einer Anfrage durch B und fährt damit fort, bis keine weiteren A mehr zu ersetzen sind.

RewriteRule "(.*)A(.*)" "$1B$2" [N]

Sie können sich dies als while-Schleife vorstellen: Solange dieses Muster noch übereinstimmt (d.h. solange der URI noch ein A enthält), führe diese Ersetzung durch (d.h. ersetze das A durch ein B).

Ab Version 2.5.0 gibt dieses Modul nach 10.000 Iterationen einen Fehler zurück, um vor unbeabsichtigten Schleifen zu schützen. Eine alternative maximale Anzahl von Iterationen kann durch Hinzufügen zum N-Flag angegeben werden.

# Bereit, 1 Zeichen pro Schleifendurchlauf zu ersetzen
RewriteRule "(.+)[><;]$" "$1" [N=32000]
# ... oder nach 10 Schleifen aufgeben
RewriteRule "(.+)[><;]$" "$1" [N=10]

NC|nocase ¶

Die Verwendung des [NC]-Flags bewirkt, dass die RewriteRule ohne Berücksichtigung der Groß-/Kleinschreibung abgeglichen wird. Das heißt, es spielt keine Rolle, ob Buchstaben im abgeglichenen URI als Groß- oder Kleinbuchstaben erscheinen.

Im folgenden Beispiel wird jede Anfrage nach einer Bilddatei an Ihren dedizierten Bildserver weitergeleitet. Der Abgleich erfolgt ohne Berücksichtigung der Groß-/Kleinschreibung, sodass beispielsweise sowohl .jpg- als auch .JPG-Dateien akzeptiert werden.

RewriteRule "(.*\.(jpg|gif|png))$" "http://images.example.com$1" [P,NC]

NE|noescape ¶

Standardmäßig werden bei einer RewriteRule, die zu einer externen Umleitung führt, alle Zeichen in der Ausgabe, die nicht in der folgenden sicheren Menge enthalten sind, in ihre Hexcode-Äquivalente (prozentcodiert) umgewandelt:

• Alphanumerische Zeichen: A-Z, a-z, 0-9
• Sonderzeichen: $-_.+!*'(),:;@&=/~

Beispielsweise würde # in %23 umgewandelt und ? in %3F. Das %-Zeichen wird ebenfalls maskiert (zu %25), was bedeutet, dass jede bereits vorhandene Prozentkodierung in der Ersetzung doppelt kodiert wird.

Die Verwendung des [NE]-Flags verhindert diese Maskierung und ermöglicht, dass Zeichen wie # und ? unverändert an die Umleitungs-URL weitergegeben werden.

RewriteRule "^/anchor/(.+)" "/bigpage.html#$1" [NE,R]

Das obige Beispiel leitet /anchor/xyz auf /bigpage.html#xyz um. Ohne [NE] würde das #-Zeichen in sein Hexcode-Äquivalent %23 umgewandelt, was dann zu einem 404-Nicht-Gefunden-Fehler führen würde.

NS|nosubreq ¶

Die Verwendung des [NS]-Flags verhindert, dass die Regel auf Unteranfragen angewendet wird. Beispielsweise ist eine Seite, die mittels SSI (Server Side Include) eingebunden wird, eine Unteranfrage, und Sie möchten möglicherweise Umschreibungen bei diesen Unteranfragen vermeiden. Auch wenn mod_dir versucht, Informationen über mögliche Standarddateien des Verzeichnisses herauszufinden (wie index.html-Dateien), handelt es sich um eine interne Unteranfrage, und Sie möchten häufig Umschreibungen bei solchen Unteranfragen vermeiden. Bei Unteranfragen ist es nicht immer nützlich und kann sogar Fehler verursachen, wenn der vollständige Regelsatz angewendet wird. Verwenden Sie dieses Flag, um problematische Regeln auszuschließen.

Um zu entscheiden, ob Sie diese Regel verwenden sollten oder nicht: Wenn Sie URLs mit CGI-Skripten voranstellen, um deren Verarbeitung durch das CGI-Skript zu erzwingen, werden Sie wahrscheinlich bei Unteranfragen auf Probleme (oder erheblichen Overhead) stoßen. In diesen Fällen verwenden Sie dieses Flag.

Bilder, JavaScript-Dateien oder CSS-Dateien, die als Teil einer HTML-Seite geladen werden, sind keine Unteranfragen - der Browser fordert sie als separate HTTP-Anfragen an.

P|proxy ¶

Die Verwendung des [P]-Flags bewirkt, dass die Anfrage von mod_proxy behandelt und über eine Proxy-Anfrage verarbeitet wird. Wenn Sie beispielsweise möchten, dass alle Bildanfragen von einem Backend-Bildserver behandelt werden, könnten Sie Folgendes tun:

RewriteRule "/(.*)\.( jpg|gif|png)$" "http://images.example.com/$1.$2" [P]

Die Verwendung des [P]-Flags impliziert [L] - das heißt, die Anfrage wird sofort durch den Proxy geleitet und nachfolgende Regeln werden nicht berücksichtigt.

Sie müssen sicherstellen, dass der Ersetzungsstring ein gültiger URI ist (typischerweise beginnend mit http://hostname), der von mod_proxy verarbeitet werden kann. Andernfalls erhalten Sie einen Fehler vom Proxy-Modul. Verwenden Sie dieses Flag, um eine leistungsfähigere Implementierung der ProxyPass-Direktive zu erreichen und entfernte Inhalte in den Namensraum des lokalen Servers einzubinden.

Hinweis: mod_proxy muss aktiviert sein, um dieses Flag verwenden zu können.

PT|passthrough ¶

Das Ziel (oder der Ersetzungsstring) in einer RewriteRule wird standardmäßig als Dateipfad behandelt. Die Verwendung des [PT]-Flags bewirkt, dass es stattdessen als URI behandelt wird. Das heißt, die Verwendung des [PT]-Flags bewirkt, dass das Ergebnis der RewriteRule durch die URL-Zuordnung zurückgeleitet wird, sodass standortbasierte Zuordnungen wie Alias, Redirect oder ScriptAlias beispielsweise wirksam werden können.

Wenn Sie beispielsweise einen Alias für /icons haben und eine RewriteRule dorthin zeigt, sollten Sie das [PT]-Flag verwenden, um sicherzustellen, dass der Alias ausgewertet wird.

Alias "/icons" "/usr/local/apache/icons"
RewriteRule "/pics/(.+)\.jpg$" "/icons/$1.gif" [PT]

Das Weglassen des [PT]-Flags in diesem Fall führt dazu, dass der Alias ignoriert wird und ein 'Datei nicht gefunden'-Fehler zurückgegeben wird.

Das PT-Flag impliziert das L-Flag: Die Umschreibung wird gestoppt, um die Anfrage an die nächste Verarbeitungsphase weiterzuleiten.

Beachten Sie, dass das PT-Flag in Verzeichniskontexten wie <Directory>-Abschnitten oder in .htaccess-Dateien impliziert ist. Die einzige Möglichkeit, dies zu umgehen, ist die Umschreibung zu -.

QSA|qsappend ¶

Wenn der Ersetzungs-URI einen Query-String enthält, ist das Standardverhalten von RewriteRule, den vorhandenen Query-String zu verwerfen und durch den neu generierten zu ersetzen. Die Verwendung des [QSA]-Flags bewirkt, dass die Query-Strings kombiniert werden.

Betrachten Sie die folgende Regel:

RewriteRule "/pages/(.+)" "/page.php?page=$1" [QSA]

Mit dem [QSA]-Flag wird eine Anfrage für /pages/123?one=two auf /page.php?page=123&one=two abgebildet. Ohne das [QSA]-Flag wird dieselbe Anfrage auf /page.php?page=123 abgebildet - das heißt, der vorhandene Query-String wird verworfen.

QSD|qsdiscard ¶

Wenn der angeforderte URI einen Query-String enthält und der Ziel-URI nicht, ist das Standardverhalten von RewriteRule, diesen Query-String in den Ziel-URI zu kopieren. Die Verwendung des [QSD]-Flags bewirkt, dass der Query-String verworfen wird.

Dieses Flag ist ab Version 2.4.0 verfügbar.

Die gemeinsame Verwendung von [QSD] und [QSA] führt dazu, dass [QSD] Vorrang hat.

Wenn der Ziel-URI einen Query-String hat, wird das Standardverhalten beobachtet - das heißt, der ursprüngliche Query-String wird verworfen und durch den Query-String im RewriteRule-Ziel-URI ersetzt.

QSL|qslast ¶

Standardmäßig trennt das erste (linkeste) Fragezeichen in der Ersetzung den Pfad vom Query-String. Die Verwendung des [QSL]-Flags weist RewriteRule an, stattdessen die beiden Komponenten beim letzten (rechtesten) Fragezeichen zu trennen.

Dies ist nützlich bei der Zuordnung zu Dateien, die literale Fragezeichen in ihrem Dateinamen haben. Wenn kein Query-String in der Ersetzung verwendet wird, kann ein Fragezeichen in Kombination mit diesem Flag angehängt werden.

Dieses Flag ist ab Version 2.4.19 verfügbar.

R|redirect ¶

Die Verwendung des [R]-Flags bewirkt, dass eine HTTP-Umleitung an den Browser gesendet wird. Wenn eine vollqualifizierte URL angegeben wird (das heißt, einschließlich http://servername/), wird eine Umleitung an diesen Ort durchgeführt. Andernfalls werden das aktuelle Protokoll, der Servername und die Portnummer verwendet, um die URL zu generieren, die mit der Umleitung gesendet wird.

Jeder gültige HTTP-Antwort-Statuscode kann angegeben werden, mit der Syntax [R=305], wobei standardmäßig ein 302-Statuscode verwendet wird, wenn keiner angegeben ist. Der angegebene Statuscode muss nicht unbedingt ein Umleitungs-(3xx-)Statuscode sein. Wenn jedoch ein Statuscode außerhalb des Umleitungsbereichs (300-399) liegt, wird der Ersetzungsstring vollständig verworfen und die Umschreibung gestoppt, als ob L verwendet worden wäre.

Zusätzlich zu Antwort-Statuscodes können Sie auch den Umleitungsstatus mit ihren symbolischen Namen angeben: temp (Standard), permanent oder seeother.

Sie werden fast immer [R] in Verbindung mit [L] verwenden wollen (also [R,L]), da das [R]-Flag allein http://thishost[:thisport] dem URI voranstellt, dies aber dann an die nächste Regel im Regelsatz weitergibt, was häufig zu 'Ungültiger URI in Anfrage'-Warnungen führen kann.

Hinweis: httpd unterstützt nur Statuscodes, die in der HTTP-Spezifikation enthalten sind. Die Verwendung eines nicht erkannten Statuscodes führt zu einem 500-Fehler und einer Fehlermeldung im Fehlerprotokoll.

S|skip ¶

Das [S]-Flag wird verwendet, um Regeln zu überspringen, die Sie nicht ausführen möchten. Die Syntax des Skip-Flags ist [S=N], wobei N die Anzahl der zu überspringenden Regeln angibt (vorausgesetzt, die RewriteRule und alle vorhergehenden RewriteCond-Direktiven stimmen überein). Dies kann als goto-Anweisung in Ihrem Umschreibungsregelsatz betrachtet werden. Im folgenden Beispiel möchten wir die RewriteRule nur ausführen, wenn der angeforderte URI keiner tatsächlichen Datei entspricht.

# Ist die Anfrage für eine nicht existierende Datei?
RewriteCond "%{REQUEST_FILENAME}" !-f
RewriteCond "%{REQUEST_FILENAME}" !-d
# Falls ja, überspringe diese zwei RewriteRules
RewriteRule ".?"                  "-" [S=2]

RewriteRule "(.*\.gif)"           "images.php?$1"
RewriteRule "(.*\.html)"          "docs.php?$1"

Diese Technik ist nützlich, weil eine RewriteCond nur auf die unmittelbar darauf folgende RewriteRule angewendet wird. Wenn Sie also eine RewriteCond auf mehrere RewriteRules anwenden möchten, besteht eine Möglichkeit darin, diese Bedingungen zu negieren und eine RewriteRule mit einem [Skip]-Flag hinzuzufügen. Sie können damit Pseudo-if-then-else-Konstrukte erstellen: Die letzte Regel der then-Klausel wird zu skip=N, wobei N die Anzahl der Regeln in der else-Klausel ist:

# Existiert die Datei?
RewriteCond "%{REQUEST_FILENAME}" !-f
RewriteCond "%{REQUEST_FILENAME}" !-d
# Erstelle ein if-then-else-Konstrukt, indem 3 Zeilen übersprungen werden, wenn wir zur "else"-Klausel wollten.
RewriteRule ".?"                  "-" [S=3]

# WENN die Datei existiert, dann:
    RewriteRule "(.*\.gif)"  "images.php?$1"
    RewriteRule "(.*\.html)" "docs.php?$1"
    # Überspringe die "else"-Klausel.
    RewriteRule ".?"         "-" [S=1]
# SONST...
    RewriteRule "(.*)"       "404.php?file=$1"
# ENDE

Es ist wahrscheinlich einfacher, diese Art der Konfiguration mit den Direktiven <If>, <ElseIf> und <Else> zu erreichen.

T|type ¶

Setzt den MIME-Typ, mit dem die resultierende Antwort gesendet wird. Dies hat denselben Effekt wie die AddType-Direktive.

Sie könnten beispielsweise die folgende Technik verwenden, um Perl-Quellcode als Klartext bereitzustellen, wenn er auf eine bestimmte Weise angefordert wird:

# .pl-Dateien als Klartext bereitstellen
RewriteRule "\.pl$"  "-" [T=text/plain]

Oder wenn Sie eine Kamera haben, die JPEG-Bilder ohne Dateiendungen produziert, könnten Sie erzwingen, dass diese Bilder mit dem korrekten MIME-Typ bereitgestellt werden, basierend auf ihren Dateinamen:

# Dateien mit 'IMG' im Namen sind jpg-Bilder.
RewriteRule "IMG"  "-" [T=image/jpg]

Bitte beachten Sie, dass dies ein triviales Beispiel ist und besser mit <FilesMatch> gelöst werden könnte. Berücksichtigen Sie immer die alternativen Lösungen für ein Problem, bevor Sie auf Umschreibung zurückgreifen, die stets eine weniger effiziente Lösung darstellt als die Alternativen.

Bei Verwendung im Verzeichniskontext verwenden Sie nur - (Bindestrich) als Ersetzung für die gesamte Runde der mod_rewrite-Verarbeitung, da sonst der mit diesem Flag gesetzte MIME-Typ durch eine interne Neuverarbeitung verloren geht (einschließlich nachfolgender Runden der mod_rewrite-Verarbeitung). Das L-Flag kann in diesem Kontext nützlich sein, um die aktuelle Runde der mod_rewrite-Verarbeitung zu beenden.

UnsafeAllow3F ¶

Das Setzen dieses Flags ist erforderlich, um eine Umschreibung fortzusetzen, wenn die zu schreibende HTTP-Anfrage ein kodiertes Fragezeichen '%3f' enthält und das umgeschriebene Ergebnis ein '?' in der Ersetzung hat. Dies schützt vor einer bösartigen URL, die eine Erfassung und Neuersetzung des kodierten Fragezeichens ausnutzt.

UnsafePrefixStat ¶

Das Setzen dieses Flags ist erforderlich bei Server-Kontext-Ersetzungen, die mit einer Variable oder Rückreferenz beginnen und zu einem Dateisystempfad aufgelöst werden. Diesen Ersetzungen wird nicht das Document Root vorangestellt. Dies schützt vor einer bösartigen URL, die die expandierte Ersetzung auf einen unerwarteten Dateisystemstandort abbilden lässt.

Available in Apache HTTP Server 2.5.1 and later.

UNC ¶

Das Setzen dieses Flags verhindert das Zusammenführen mehrerer führender Schrägstriche, wie sie in Windows-UNC-Pfaden verwendet werden. Das Flag ist nicht erforderlich, wenn die Regelersetzung mit mehreren literalen Schrägstrichen beginnt.

Available in Apache HTTP Server 2.5.1 and later.