wake-up-neo.com

RewriteCond in .htaccess mit negierter Regex-Bedingung funktioniert nicht?

Ich versuche, in diesem Fall WordPress daran zu hindern, bestimmte URLs neu zu schreiben. In diesem Fall versuche ich zu verhindern, dass er jemals eine Anfrage im Upload-Verzeichnis bearbeitet, und überlasse diese stattdessen der 404-Seite des Servers. Ich gehe also davon aus, dass es so einfach ist, wie die Regel hinzuzufügen:

RewriteCond %{REQUEST_URI} !^/wp-content/uploads/

Diese Regel sollte als falsch ausgewertet werden und dazu führen, dass die Regelkette für diese Anforderungen fehlschlägt, wodurch das Neuschreiben gestoppt wird. Aber nein ... Vielleicht muss ich dem Cover die gesamte Zeichenfolge in meinem Ausdruck zuordnen?

RewriteCond %{REQUEST_URI} !^/wp-content/uploads/.*$

Nein, das ist es auch nicht. Nachdem ich mir am Kopf gekratzt habe, überprüfe ich die Gesundheit. Vielleicht stimmt etwas nicht mit dem tatsächlichen Muster. Also mache ich einen einfachen Testfall.

RewriteCond %{REQUEST_URI} ^/xyz/$

In diesem Fall erfolgt das Umschreiben genau dann, wenn die angeforderte URL/xyz/lautet und die 404-Seite des Servers für eine andere Seite angezeigt wird. Genau das habe ich erwartet. Also bleibe ich einfach dabei! dieses Muster zu negieren.

RewriteCond %{REQUEST_URI} !^/xyz/$

Jetzt erwarte ich das genaue Gegenteil der obigen Bedingung. Das Umschreiben sollte nicht für/xyz/erfolgen, sondern für jede andere mögliche URL. Stattdessen erfolgt das Umschreiben für jede URL, sowohl für/xyz/als auch für andere.

Entweder ist die Verwendung negierter regulärer Ausdrücke in RewriteConds in Apache fehlerhaft, oder es gibt etwas Grundlegendes, das ich nicht verstehe. Welches ist es?

Der Server ist Apache2.

Die Datei in ihrer Gesamtheit:

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteBase /
RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/wp-content/uploads/
RewriteRule . /index.php [L]
</IfModule>

Die Standarddatei von WordPress plus meine Regel.

17
nitro2k01

Nach einiger Irritation fand ich das Problem irgendwie heraus. Wie sich herausstellte, hat die Regel in meiner ursprünglichen Frage genau das getan, was sie tun sollte. Es gab auch eine Reihe anderer Möglichkeiten, das Gleiche zu tun, z

RewriteRule ^wp-content/uploads/.*$ - [L]

(Regel als letzte kennzeichnen, wenn Muster übereinstimmt) oder

RewriteRule ^wp-content/uploads/.*$ - [S=1]

(Überspringen Sie die nächste Regel, wenn das Muster übereinstimmt) sowie die negierte Regel in der Frage, wie erwähnt. Alle diese Regeln funktionierten gut und gaben die Kontrolle an Apache zurück, ohne sie neu schreiben zu müssen.

Das Problem trat auf, nachdem diese Regeln verarbeitet wurden. Stattdessen bestand das Problem darin, dass ich die Standardvorlagen 404.shtml, 403.shtml usw. löschte, die mein Host bereitgestellt hatte. Wenn Sie keine .htaccess-Umschreibungen haben, funktioniert das einwandfrei. Der Server wird eine eigene Standard-404-Seite erstellen und alles funktioniert. (Zumindest dachte ich es, aber in Wirklichkeit war es der Doppelfehler "Außerdem wurde beim Versuch, ein ErrorDocument zur Verarbeitung der Anforderung zu verwenden, ein 404-Fehler gefunden.").

Wenn Sie jedoch über einen .htaccess verfügen, wird er für die 404-Seite ein zweites Mal ausgeführt. Wenn die Seite vorhanden ist, wird sie verwendet, aber stattdessen wurde die Anforderung für 404.shtml von der Catch-All-Regel abgefangen und in index.php umgeschrieben. Aus diesem Grund sind alle anderen Vorschläge, die ich hier oder anderswo erhalten habe, alle fehlgeschlagen, da die 404-Seite am Ende in index.php umgeschrieben wurde.

Die Lösung bestand also einfach darin, die Fehlervorlagen wiederherzustellen. Im Nachhinein war es ziemlich dumm, sie zu löschen, aber ich habe diese Mentalität "von vorne anfangen". Ich will nichts scheinbar unnötiges herumliegen. Zumindest verstehe ich jetzt, was los war, was ich wollte.

Zum Schluss noch ein Kommentar zu Cecil: Ich wollte nie den Zugriff auf irgendetwas verbieten, ich möchte nur verhindern, dass das Umschreiben stattfindet. Nicht, dass es jetzt wichtig ist, aber ich wollte das nur klarstellen.

7
nitro2k01
<IfModule mod_rewrite.c>
RewriteEngine On

RewriteBase /
RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_URI} !^/wp-content/uploads/ [OR]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]
</IfModule>
9
Cecil

Wenn /wp-content/uploads/ wirklich das Präfix des angeforderten URI-Pfads ist, sollte Ihre Regel wie erwartet funktionieren.

Da dies offensichtlich nicht funktioniert, versuchen Sie, nicht mit dem Pfadpräfix des vollständigen URI-Pfads übereinzustimmen, sondern nur den verbleibenden Pfad ohne das kontextabhängige Pfadpräfix für jedes Verzeichnis, im Fall der .htaccess-Datei im Dokumentstammverzeichnis den URI-Pfad ohne den führenden /:

RewriteCond $0 !^wp-content/uploads/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .+ /index.php [L]

Wenn dies auch nicht funktioniert, würde es sicherlich hilfreich sein, einen Einblick in den Umschreibungsprozess von mod_rewrite zu erhalten, indem seine Protokollierungsfunktion verwendet wird. Setzen Sie also RewriteLogLevel auf eine Stufe von mindestens 4, stellen Sie Ihre Anfrage und sehen Sie sich die Einträge in der mit RewriteLog angegebenen Protokolldatei an. Dort können Sie sehen, wie mod_rewrite Ihre Anfrage bearbeitet, und mit RewriteLogLevel größer oder gleich 4 werden auch die Werte von Variablen wie %{REQUEST_URI} angezeigt.

2
Gumbo

Ich habe viele Beispiele dieser Art gefunden, wenn ich einen "WordPress First" -Ansatz nehme. Zum Beispiel:

ErrorDocument 404 /error-docs/404.html

in der .htaccess-Datei kümmert sich um die Nachricht ("Darüber hinaus einen 404-Fehler nicht gefunden ...").

0
cbos