Welchen Vorrang haben mehrere mod_rewrite-Regeln in mehreren .htaccess-Dateien? [geschlossen]

Das [L] Flag bedeutet zwar "last", aber es gilt nur für die Regeln im aktuellen Bereich. Von Ihrer Frage betrifft es nur die Regeln in der htaccess-Datei. Wenn sich in einem Unterverzeichnis Regeln befinden, werden alle Regeln im übergeordneten Verzeichnis aus dem Fenster geworfen. Sie werden überhaupt nicht angewendet, es sei denn, Sie verwenden die Direktive RewriteOptions Inherit (die alle Regeln aus der übergeordneten htaccess-Datei an das Ende der Regeln anfügt).

In Ihrem Beispiel:

Wenn es htaccess-Dateien in A, B und C gibt und Regeln in allen 3 umschreibt, wenn man http://root.com anfordert (Ihr "root.com" -Verzeichnis), werden nur die Regeln in A angewendet. Wenn jemand http://root.com/subdirectory1 anfordert, werden nur die Regeln in B angewendet, und alle Regeln in A werden ignoriert (ohne die Option Inherit ). Ebenso, wenn jemand zu http://root.com/subdirectory1/subdirectory2 geht, werden nur die Regeln in C angewendet, wenn es keine erbenden Optionen gibt.

Das Flag [L] hat in diesem Fall keine Bedeutung, da der Bereich hier nur innerhalb der Regeln einer htaccess-Datei liegt. Beachten Sie auch, dass [L] nicht unbedingt bedeutet "stop rewriting HIER " zu stoppen, da die Rewrite-Engine eine Schleife ausführt, bis der URI, der in den Motor geht, sich nicht mehr ändert. Das [L] bedeutet nur, dass das Umschreiben in der aktuellen Iteration der Schleife der Neuschreibe-Engine gestoppt wird.

Ein bisschen mehr Details zum Looping:

Während der URL-Verarbeitungspipeline versucht apache, eine URL einer Datei oder Ressource zuzuordnen. Viele verschiedene Module spielen eine Rolle in der Verarbeitungspipeline, wie mod_rewrite oder mod_proxy oder mod_alias. Dieser URI kann sich jederzeit ändern, zur Umleitung markiert sein, als Proxy gekennzeichnet sein, zum Auslösen eines Fehlers gekennzeichnet sein usw. Wenn der URI zu mod_rewrite gelangt, sammelt die Rewrite-Engine eine Reihe von Regeln aus der vhost-Konfiguration und die entsprechende htaccess-Datei; Beachten Sie, hier 2 verschiedene Bereiche. Jeder Regelbereich wird auf den URI angewendet und wenn keine der Regeln übereinstimmt, ist mod_rewrite erledigt. Wenn eine der Regeln übereinstimmt, gibt es eine interne Weiterleitung , was bedeutet, dass der URI geändert und dann zurück an die Verarbeitungspipeline und mod_rewrite weitergeleitet wird. Somit wird der gleiche Regelbereich wieder angewendet, und wenn eine der Regeln übereinstimmt und angewendet wird, passiert das Gleiche wieder mit der Regelschleife. Es gibt eine Direktive, die Sie in der vhost / server config mit dem Namen LimitInternalRecursion einstellen können, die das Limit dieser internen Redirects festlegt. Wenn die Anzahl der Wiederholungen der Rewrite-Engine (d. H. Weiterleitung an sich selbst) diese Grenze überschreitet (was standardmäßig 10 ist, denke ich), dann erhalten Sie einen 500 Internal Server-Fehler.

Das hört sich komisch an, aber es gibt viele Beispiele dafür. Beispiel: Entferne alle _ von der URI und ersetze sie mit - :

Wenn der URI /a_b_c_d_foo ist, dann wird der URI beim ersten Mal in /a_b_c_d-foo geändert, dann wird er wiederholt und in '/a_b_c-d-foo geändert, dann wieder /a_b-c-d-foo und zum 5. Mal bekommt man /a-b-c-d-foo . Es wird erneut eine Schleife durchlaufen, aber da das ^(.*)_(.*)$ -Muster nicht übereinstimmt, durchläuft der URI die Rewrite-Engine und die Schleife stoppt.

Das Problem tritt auf, wenn Benutzer Regeln erstellen, die das Schleifen nicht berücksichtigen, zum Beispiel: rewrite /<anything> in /foo/<anything> :

Wenn der URI /bar ist, wird der URI zum ersten Mal in /foo/bar umgeschrieben, und dies ist das gewünschte Ergebnis. Aber der URI wird intern zurück in die Rewrite-Engine umgeleitet und die gleiche Regel wird erneut abgeglichen, was: /foo/foo/bar , dann wieder: /foo/foo/foo/bar und wieder: /foo/foo/foo/foo/bar , bis das interne Rekursionslimit erreicht ist und Sie erhalten Ein 500 Server Fehler.