Technische Details zu Apache mod_rewrite

API-Phasen ¶

Der Apache HTTP Server bearbeitet Anfragen in mehreren Phasen. In jeder dieser Phasen können ein oder mehrere Module aufgerufen werden, um diesen Teil des Anfrage-Lebenszyklus zu behandeln. Zu den Phasen gehören Dinge wie URL-zu-Dateiname-Übersetzung, Authentifizierung, Autorisierung, Inhalt und Protokollierung. (Dies ist keine vollständige Liste.)

mod_rewrite wirkt in zwei dieser Phasen (oder "Hooks", wie sie oft genannt werden), um zu beeinflussen, wie URLs umgeschrieben werden können.

Erstens verwendet es den URL-zu-Dateiname-Übersetzungs-Hook, der nach dem Lesen der HTTP-Anfrage stattfindet, aber bevor eine Autorisierung beginnt. Zweitens verwendet es den Fixup-Hook, der nach den Autorisierungsphasen und nach dem Lesen der verzeichnisbezogenen Konfigurationsdateien (.htaccess-Dateien) stattfindet, aber bevor der Inhalts-Handler aufgerufen wird.

Nachdem eine Anfrage eingegangen ist und ein entsprechender Server oder virtueller Host bestimmt wurde, beginnt die Umschreibungs-Engine mit der Verarbeitung aller mod_rewrite-Direktiven in der Server-Konfiguration. (d.h. in der Hauptserverkonfigurationsdatei und in <Virtualhost>-Abschnitten.) Dies geschieht in der URL-zu-Dateiname-Phase.

Einige Schritte später, nachdem die endgültigen Datenverzeichnisse gefunden wurden, werden die verzeichnisbezogenen Konfigurationsdirektiven (.htaccess-Dateien und <Directory>-Blöcke) angewendet. Dies geschieht in der Fixup-Phase.

In jedem dieser Fälle schreibt mod_rewrite die REQUEST_URI entweder auf eine neue URL oder auf einen Dateinamen um.

Im Verzeichniskontext (d.h. in .htaccess-Dateien und Directory-Blöcken) werden diese Regeln angewendet, nachdem eine URL bereits in einen Dateinamen übersetzt wurde. Aus diesem Grund ist der URL-Pfad, gegen den mod_rewrite zunächst die RewriteRule-Direktiven abgleicht, der vollständige Dateisystempfad zum übersetzten Dateinamen, wobei der Pfad des aktuellen Verzeichnisses (einschließlich eines abschließenden Schrägstrichs) vom Anfang entfernt wurde.

Zur Veranschaulichung: Wenn Regeln in /var/www/foo/.htaccess stehen und eine Anfrage für /foo/bar/baz verarbeitet wird, würde ein Ausdruck wie ^bar/baz$ übereinstimmen.

Wenn eine Ersetzung im Verzeichniskontext vorgenommen wird, wird eine neue interne Unteranfrage mit der neuen URL ausgelöst, die die Verarbeitung der Anfragephasen neu startet. Wenn die Ersetzung ein relativer Pfad ist, bestimmt die RewriteBase-Direktive das URL-Pfad-Präfix, das der Ersetzung vorangestellt wird. Im Verzeichniskontext muss darauf geachtet werden, Regeln zu erstellen, die letztendlich (in einer zukünftigen "Runde" der verzeichnisbezogenen Umschreibungsverarbeitung) keine Ersetzung durchführen, um Schleifen zu vermeiden. (Siehe RewriteLooping für eine weitere Diskussion dieses Problems.)

Aufgrund dieser weiteren Manipulation der URL im Verzeichniskontext müssen Sie Ihre Umschreibungsregeln in diesem Kontext anders gestalten. Insbesondere denken Sie daran, dass der führende Verzeichnispfad vom URL-Pfad abgeschnitten wird, den Ihre Umschreibungsregeln sehen. Betrachten Sie die folgenden Beispiele zur weiteren Verdeutlichung.

Ort der Regel	Regel
VirtualHost-Abschnitt	RewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"
.htaccess-Datei im Document Root	RewriteRule "^images/(.+)\.jpg" "images/$1.gif"
.htaccess-Datei im images-Verzeichnis	RewriteRule "^(.+)\.jpg" "$1.gif"

Für noch mehr Einblick, wie mod_rewrite URLs in verschiedenen Kontexten manipuliert, sollten Sie die Protokolleinträge konsultieren, die während der Umschreibung erstellt werden.

Regelsatz-Verarbeitung ¶

Wenn mod_rewrite in diesen beiden API-Phasen ausgelöst wird, liest es die konfigurierten Regelsätze aus seiner Konfigurationsstruktur (die entweder beim Start für den Server-Kontext oder während des Verzeichnisdurchlaufs des Apache-Kerns für den Verzeichniskontext erstellt wurde). Dann wird die URL-Umschreibungs-Engine mit dem enthaltenen Regelsatz gestartet (eine oder mehrere Regeln zusammen mit ihren Bedingungen). Die Funktionsweise der URL-Umschreibungs-Engine ist für beide Konfigurationskontexte genau gleich. Nur die endgültige Ergebnisverarbeitung ist unterschiedlich.

Die Reihenfolge der Regeln im Regelsatz ist wichtig, da die Umschreibungs-Engine sie in einer speziellen (und nicht sehr offensichtlichen) Reihenfolge verarbeitet. Die Regel lautet: Die Umschreibungs-Engine durchläuft den Regelsatz Regel für Regel (RewriteRule-Direktiven) und wenn eine bestimmte Regel übereinstimmt, durchläuft sie optional die vorhandenen zugehörigen Bedingungen (RewriteCond-Direktiven). Aus historischen Gründen werden die Bedingungen zuerst angegeben, sodass der Kontrollfluss etwas umständlich ist. Siehe Abbildung 1 für weitere Details.

Abbildung 1:Der Kontrollfluss durch den Umschreibungsregelsatz

Zuerst wird die URL gegen das Pattern jeder Regel abgeglichen. Wenn es fehlschlägt, stoppt mod_rewrite sofort die Verarbeitung dieser Regel und fährt mit der nächsten Regel fort. Wenn das Pattern übereinstimmt, sucht mod_rewrite nach zugehörigen Regelbedingungen (RewriteCond-Direktiven, die in der Konfiguration unmittelbar über der RewriteRule stehen). Wenn keine vorhanden sind, ersetzt es die URL durch einen neuen Wert, der aus dem String Substitution konstruiert wird, und fährt mit seiner Regelschleife fort. Wenn jedoch Bedingungen vorhanden sind, startet es eine innere Schleife zur Verarbeitung dieser in der Reihenfolge, in der sie aufgeführt sind. Für Bedingungen ist die Logik anders: Wir gleichen kein Muster gegen die aktuelle URL ab. Stattdessen erstellen wir zuerst einen String TestString durch Expansion von Variablen, Rückreferenzen, Map-Nachschlagungen usw., und dann versuchen wir, CondPattern dagegen abzugleichen. Wenn das Muster nicht übereinstimmt, schlägt die gesamte Menge von Bedingungen und die zugehörige Regel fehl. Wenn das Muster übereinstimmt, wird die nächste Bedingung verarbeitet, bis keine weiteren Bedingungen verfügbar sind. Wenn alle Bedingungen übereinstimmen, wird die Verarbeitung mit der Ersetzung der URL durch Substitution fortgesetzt.