htaccess RewriteRule in der <if> -Anweisung mit HTTP_HOST

Sep 21 2020

Ich führe mehrere Sites auf einem Server aus einer .htaccess-Datei mit einem benutzerdefinierten Site-Design aus, das eine Seite verwendet (index.php? PageID = x). Abhängig von der Seiten-ID werden unterschiedliche Inhalte / Layouts ausgelöst.

Für jede Site verwende ich eine IF-Anweisung in .htccess, zum Beispiel:

<If "%{HTTP_HOST} == 'site.com'">     
RewriteRule goes here
</If>

Wenn ich nicht in der IF-Anweisung bin, verwende ich eine Umschreiberegel wie die folgende:

RewriteRule ^fr/cookie-policy/$ /index.php?pageid=11 [L]

Die obige Regel funktioniert wie geplant, aber wenn ich diese Regel in der IF-Anweisung verwende, funktioniert sie nicht. Ich muss das führende ^ entfernen und es gegen ein / tauschen. Dies ist jedoch alles andere als ideal, da alles, was endet, mit einem bestimmten Muster übereinstimmt.

Kann jemand eine Lösung vorschlagen? Was fehlt mir?

Antworten

2 MrWhite Sep 22 2020 at 08:44

Der <If>Container ändert die Reihenfolge der Verarbeitung. <If>Container werden sehr spät zusammengeführt . Siehe: Wie Abschnitte in den Apache-Dokumenten zusammengeführt werden

Dies führt zu den RewriteRuleAnweisungen innerhalb des <If>Abgleichs mit dem absoluten Dateisystempfad, dem die Anforderung zugeordnet wurde, einschließlich des Verzeichnispräfixes, das normalerweise beim Abgleich in einem Verzeichniskontext (dh .htaccess) entfernt wird. (Möglicherweise wurde die Anforderung zum Zeitpunkt der <If>Verarbeitung des Abschnitts wieder dem Dateisystem zugeordnet ?)

RewriteRule ^fr/cookie-policy/$ /index.php?pageid=11 [L]

Wenn also fr/cookie-policy/relativ zum Document - Root und das DocumentRootist /var/www/user/public_htmldann diese passen genau , müssen Sie gegen übereinstimmen /var/www/user/public_html/fr/cookie-policy/.

Ich sehe keine Möglichkeit, dies zu vermeiden, es sei denn, Sie verwenden eine zusätzliche Bedingung (und prüfen sie anhand der REQUEST_URIServervariablen) - aber das scheint den Punkt zu vereiteln (und wäre weniger effizient).

Es wird alles, was endet, mit einem bestimmten Muster abgleichen.

Ohne Angabe des vollständigen absoluten Dateipfads könnten Sie möglicherweise nur das übergeordnete Verzeichnis (dh eines über dem Dokumentstamm) einfügen, um die Wahrscheinlichkeit zu verringern, dass dies geschieht. z.B. public_html/fr/cookie-policy/$.


Einige andere (bizarre) Einschränkungen, die mir bei der Verwendung von mod_rewrite in einem <If>Abschnitt aufgefallen sind :

  • Sie können nicht in einen relativen Pfad umschreiben (dh nicht mit einem Schrägstrich oder Schema + Hostname beginnen). Es muss mit einem Schrägstrich beginnen (dh root-relativ). Das Umschreiben auf einen relativen Pfad in einem Verzeichniskontext führt normalerweise dazu, dass das Verzeichnispräfix wieder hinzugefügt wird. Innerhalb des <If>Containers scheint das Verzeichnispräfix jedoch als *If/- angesehen zu werden, was wahrscheinlich zu einer "400 Bad Request" führt. (Vielleicht liegt das daran, dass zum Zeitpunkt des <If>Zusammenführens des Abschnitts das Verzeichnispräfix bereits wieder hinzugefügt wurde?)

  • In Bezug auf oben wird die RewriteBaseRichtlinie "ignoriert".

  • Andere mod_rewrite-Direktiven außerhalb des <If>Abschnitts ( zumindest im selben Kontext ) scheinen dasselbe Verhalten anzunehmen und stimmen jetzt auch nur mit dem vollständigen absoluten Dateisystempfad überein.

  • Obwohl <If>Abschnitte "spät" zusammengeführt werden. Sie werden noch vor anderen Mod-Rewrite-Anweisungen außerhalb des <If>Abschnitts verarbeitet. Unabhängig von der Reihenfolge der Richtlinien. (Zumindest im selben Kontext.)

  • Siehe auch: Die -Bedingung mit HTTP_HOST in htaccess unterbricht PHP

Wenn Sie das überprüfen müssen, HTTP_HOSTbevor Sie eine bestimmte Umschreibung anwenden , überprüfen Sie dies normalerweise in einer vorhergehenden RewriteCond(Bedingung). Aber das weißt du schon