.htaccess - Wie viele RewriteRules?

[Matthias Scharwies]

Servus!

ich möchte den Zugang auf meiner Homepage durch einfachere Links erleichtern. Wie viele RewriteRule kann/ sollte /darf man haben?

Ich habe gelesen, dass sie jeden HTTP-Request einbremsen, da sie alle durchlaufen werden. Bringt das mess- bzw. spürbare Nachteile?

Würdet Ihr's einfach weglassen?

# convenience shortcut
RewriteCond %{REQUEST_URI} edit/?$
RewriteRule edit(/|$) /site/edit/index.html [R=permanent,L]
RewriteRule eltern(/|$) /site/fam/eltern/index.html [R=permanent,L]
RewriteRule sprechstunden(/|$) /site/wie/sprechstunden/index.html [R=permanent,L]
RewriteRule termine(/|$) /site/wie/termine/index.html [R=permanent,L]
...

Herzliche Grüße

Matthias Scharwies

[Christian Kruse]

Hallo Matthias,

ich möchte den Zugang auf meiner Homepage durch einfachere Links erleichtern. Wie viele RewriteRule kann/ sollte /darf man haben?

Das lässt sich so pauschal nicht beantworten, das hängt von vielen Faktoren ab (Traffic, Skalierung, Stärke der Computer, …)

Ich habe gelesen, dass sie jeden HTTP-Request einbremsen, da sie alle durchlaufen werden. Bringt das mess- bzw. spürbare Nachteile?

Sicherlich verlangsamt es die Verarbeitung des Requests; ob du den Preis bereit bist zu zahlen musst du allerdings ausprobieren.

Würdet Ihr's einfach weglassen? […]

Nein. Derartige Short-URLS sind vor allem in der mündlichen Kommunikation durchaus angenehm. Es stellt sich mir nur die Frage, warum du so komplizierte URLs hast und nicht einfach per se die einfachen verwendest und dann von den alten, komplizierten auf die neuen, unkomplizierten umleitest.

LG,
CK

[pl]

Servus!

ich möchte den Zugang auf meiner Homepage durch einfachere Links erleichtern. Wie viele RewriteRule kann/ sollte /darf man haben?

Die Frage ist doch, warum Du überhaupt mehr als eine Regel brauchst. Oder abstrakt gefragt: Gibt es eine Lösung für eine bestimmte Aufgabe die der Webserver performanter/zweckmäßiger/sicherer hinkriegt, als die eigene Software?

RewriteCond %{REQUEST_URI} edit/?$

Das z.B. ist eine Sache die ich ganz bestimmt nicht dem Server überlassen sondern im eigenen Framework regeln würde, so würden alle nachfolgenden Regeln in der Serverkonfiguration schonmal wegfallen.

[dedlfix]

Tach!

Die Frage ist doch, warum Du überhaupt mehr als eine Regel brauchst. Oder abstrakt gefragt: Gibt es eine Lösung für eine bestimmte Aufgabe die der Webserver performanter/zweckmäßiger/sicherer hinkriegt, als die eigene Software?

Hat er denn eine eigene Software?

Das z.B. ist eine Sache die ich ganz bestimmt nicht dem Server überlassen sondern im eigenen Framework regeln würde, so würden alle nachfolgenden Regeln in der Serverkonfiguration schonmal wegfallen.

Das löst das Problem nicht, das verlagert es nur in eine andere Ebene. Irgendwo muss das Routing stattfinden. Das einfachste und schnellste ist, wenn der Webserver statische Dateien direkt auf den Request hin ausliefern kann.

dedlfix.

[pl]

Wir meinen in diesem Fall beide dasselbe. Nur wird das hier unterschiedlich bewertet ;)

[Gunnar Bittersmann]

@@pl

Wir meinen in diesem Fall beide dasselbe.

Nein. Du meinst, eine Weiterleitung mit einer serverseitigen Technik (vermutlich Perl) zu implementieren, obwohl Apache (bzw. anderer Webserver) genau das schon bietet.

dedlfix meint,

1. dass das sinnlos ist und
2. dass das eigentliche Problem dann immer noch besteht, nur an anderer Stelle.

Nur wird das hier unterschiedlich bewertet ;)

Zu recht.

LLAP 🖖

[dedlfix]

Tach!

Wir meinen in diesem Fall beide dasselbe.

Vermutlich nicht. Irgendeine Art Performance-Problem (und sei es auch nur ein gefühltes) wird ja wohl der Auslöser der Frage gewesen sein. Wenn man ein Routing zu den auszuliefernden Dokumenten braucht, das mehr machen muss, als im Dateisystem 1:1 eine Datei anzusprechen, dann ist es im Prinzip egal, ob das mit RewriteRules oder in einer anderen Software erledigt wird. Es nimmt nicht zwangsläufig Last vom System, wenn man das statt im Apachen in der eigenen Software macht.

Daraus folgt, wenn man ein Performance-Problem mit zu vielen Rewrite-Rules hat, wird man das nicht wesentlich durch einen gleichartigen Ersatz lösen können. Es sei denn, das eine System arbeitet aus irgendeinem Grunde umständlicher und deswegen signifikant langsamer.

Vielleicht ist die Antwort auf die eigentliche Frage auch: einfach laufen lassen. Dazu müste man aber mal die Auslastung des Systems sehen. Tools wie Munin malen schöne Grafiken.

In erster Linie ist aber nicht die Prozessorlast maßgeblich, sondern die Auslieferungszeit. Wenn diese trotz vieler Regeln weiterhin akzeptabel ist, dann muss man sich fragen, ob die Performance-Bedenken in dem Fall vernachlässigbar sind.

dedlfix.

[TS]

Hallo und guten Morgen,

Das z.B. ist eine Sache die ich ganz bestimmt nicht dem Server überlassen sondern im eigenen Framework regeln würde, so würden alle nachfolgenden Regeln in der Serverkonfiguration schonmal wegfallen.

Das löst das Problem nicht, das verlagert es nur in eine andere Ebene. Irgendwo muss das Routing stattfinden. Das einfachste und schnellste ist, wenn der Webserver statische Dateien direkt auf den Request hin ausliefern kann.

Das macht das Ganze aber übersichtlicher und viel leichter pflegbar. Und wenn ein Dokument erloschen ist, oder aber wegen mangelnder Zugriffsrechte des Clients nicht angezeigt werden soll, lässt sich das in der Logik des Rahmenprogramms viel leichter regeln.

Ich habe immer nur

.htaccess

RewriteEngine on
RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f   
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteCond %{REQUEST_FILENAME} !-l

RewriteRule (.*) index.php/$1 [QSA]

drinstehen. Den Rest regelt dann das Rahmenprogramm.

So kann man dann auch die Rewrite Rules in die Virt-Host-Konfiguration nehmen, da sie für das gesamte System einheitlich sind. Das beschleunigt die Auswertung enorm. Und das Rahmenprogramm muss doch für komplexere oder zeitabhängige Seiten sowieso meistens geladen und initialisiert werden.

Es kommen ggf. noch zwei Regeln dazu, wenn es auch Subrequests mit MIME-Type-Konversion^[1] gibt, also z. B. von Zugriffsrechten betroffene Bilder / Galerien / PDF-Dokumente, o. ä.

Grüße
TS

---

1. anstelle des Dokumentes soll ein Skript aufgerufen werden. ↩︎

[dedlfix]

Tach!

Das einfachste und schnellste ist, wenn der Webserver statische Dateien direkt auf den Request hin ausliefern kann.

Das macht das Ganze aber übersichtlicher und viel leichter pflegbar. Und wenn ein Dokument erloschen ist, oder aber wegen mangelnder Zugriffsrechte des Clients nicht angezeigt werden soll, lässt sich das in der Logik des Rahmenprogramms viel leichter regeln.

Das kommt darauf an, was man erreichen möchte. Ein Apache hat ErrorDocuments für all diese Zustände. Die kann man auch selbst gestalten. Und in einfachen Fällen wären diese Probleme damit schon gelöst.

Wir wissen immer noch nicht, ob überhaupt ein CMS im Einsatz ist. Das Umschreiben auf .html kann die Vermutung aufwerfen, dass dem nicht so ist und es sich lediglich um statische Seiten handelt. Dann würde es auch nichts bringen, beispielsweise ein PHP-Script zu erstellen, das als Router fungiert.

dedlfix.

[TS]

Hallo und guten Morgen,

Wir wissen immer noch nicht, ob überhaupt ein CMS im Einsatz ist. Das Umschreiben auf .html kann die Vermutung aufwerfen, dass dem nicht so ist und es sich lediglich um statische Seiten handelt. Dann würde es auch nichts bringen, beispielsweise ein PHP-Script zu erstellen, das als Router fungiert.

Dann könnte man ja auch durch praktisch organisierte Directory-Struktur und den von Dir erwähnten Directory-Index erreichen, dass (als Beispiel) immer nach der index.php, index.html im Verzeichnis gesucht wird und man benötigt gar keine Rewrite-Rules. Und wenn es ganz doll werden soll, dann könnte die index.php auch lediglich eine Umleitung enthalten auf das eigentliche Dokument. Ist aber die Frage, wie es nach außen auch für Suchmaschinen aussehen soll. Vermutlich sollen die doch dann nach und nach umerzogen werden, um anstelle der komplizierten URi den vereinfachten Pfad zu benutzen, oder?

Fragen über Fragen ;-)

So Matthias, nun musst Du dich entscheiden. Möchtest Du das Prolem noch lösen, oder möchtest Du lieber vorher noch ein hübsches Blondes mit uns vernaschen?

Bis nachher!

Grüße
TS

[Matthias Scharwies]

Servus!

Fragen über Fragen ;-)

So Matthias, nun musst Du dich entscheiden. Möchtest Du das Prolem noch lösen, oder möchtest Du lieber vorher noch ein hübsches Blondes mit uns vernaschen?

Genau so!

Dann kauen wir durch was ich jetzt auf die schnelle nur so halb verstanden habe (ja ich habe ein CMS, dessen Ordner/ Inhaltsstruktur ich für die Navigation ganz logisch finde. Allerdings haben wir auch Print-Produkte mit ewig langen Links, die ich gerne abkürzen würde.).

Bis nachher!

Ich freu mich

Herzliche Grüße

Matthias Scharwies

PS: Self-Treffen heut abend!

[dedlfix]

Tach!

# convenience shortcut
RewriteCond %{REQUEST_URI} edit/?$
RewriteRule edit(/|$) /site/edit/index.html [R=permanent,L]
RewriteRule eltern(/|$) /site/fam/eltern/index.html [R=permanent,L]
RewriteRule sprechstunden(/|$) /site/wie/sprechstunden/index.html [R=permanent,L]
RewriteRule termine(/|$) /site/wie/termine/index.html [R=permanent,L]
...

Zumindest diese Regeln kann man mit einem DirectoryIndex index.html erschlagen. Achte darauf, dass deine Links dann immer mit / enden, sonst schickt der Server erstmal nur einen Redirect auf .../ als Antwort. Wenn jemand von außen kommend den / weglässt, dann ist das eben so, aber es muss ja nicht bei jedem intern geklickten Link erstmal eine Weiterleitung geben.

dedlfix.

[MudGuard]

Hi,

# convenience shortcut
RewriteCond %{REQUEST_URI} edit/?$
RewriteRule edit(/|$) /site/edit/index.html [R=permanent,L]
RewriteRule eltern(/|$) /site/fam/eltern/index.html [R=permanent,L]
RewriteRule sprechstunden(/|$) /site/wie/sprechstunden/index.html [R=permanent,L]
RewriteRule termine(/|$) /site/wie/termine/index.html [R=permanent,L]
...

Zumindest diese Regeln kann man mit einem DirectoryIndex index.html erschlagen.

Kann man?

Die letzte Regel z.B. macht aus
http://example.org/termine
http://example.org/site/wie/termine/index.html

Wie bekommt man das mit DirectoryIndex hin? Hier passiert ja mehr als nur das Anhängen des index.html ...

Oder irre ich hier?

cu,
Andreas a/k/a MudGuard

[dedlfix]

Tach!

Oder irre ich hier?

Nein, ich irrte mich. Hab nicht genau hingeschaut und den langen Rattenschwanz an Verzeichnissen übersehen.

Übrigens, eine .htaccess wird mit jedem Request gesucht, geladen und neu eingelesen. Regel in der Hauptkonfiguration des Apachen werden nur beim Start eingelesen und stehen dann direkt zur Verfügung. Für die benötigt der Apache dann aber sicher etwas mehr Hauptspeicher.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Übrigens, eine .htaccess wird mit jedem Request gesucht, geladen und neu eingelesen. Regel in der Hauptkonfiguration des Apachen werden nur beim Start eingelesen und stehen dann direkt zur Verfügung. Für die benötigt der Apache dann aber sicher etwas mehr Hauptspeicher.

Oh, vorsicht! Es ist richtig, dass die Regeln nur einmal gelesen werden, aber sie werden bei jedem Request neu ausgewertet; durch das sehr flexible Konfigurationsmodell muss bei jedem Request die tatsächliche Konfiguration für diesen Request bestimmt werden; und das sogar in mehreren Phasen, sprich es passiert nicht nur einmal sondern in Stufen mehrfach.

LG,
CK

[dedlfix]

Tach!

Oh, vorsicht! Es ist richtig, dass die Regeln nur einmal gelesen werden, aber sie werden bei jedem Request neu ausgewertet; durch das sehr flexible Konfigurationsmodell muss bei jedem Request die tatsächliche Konfiguration für diesen Request bestimmt werden; und das sogar in mehreren Phasen, sprich es passiert nicht nur einmal sondern in Stufen mehrfach.

Ja klar, müssen die Regeln immer wieder angewendet werden, das geht ja auch nicht anders, um vom Request zur auszuliefernden Datei / zum zu startenden Programm zu kommen. Aber dazu können sie ja in einer schneller verarbeitbaren internen Form vorliegen und müssen nicht jedes Mal neu geparst werden. So zumindest in meiner Theorie. Ob es der Apache so macht oder lieber neu parst, weiß ich nicht.

dedlfix.

[Christian Kruse]

Hallo dedlfix,

Ja klar, müssen die Regeln immer wieder angewendet werden, [...]

Nicht nur angewendet, auch ausgewertet :-) Und ja, das ist (bei Apache) ein Unterschied.

Aber dazu können sie ja in einer schneller verarbeitbaren internen Form vorliegen und müssen nicht jedes Mal neu geparst werden.

Das ist richtig. Deshalb habe ich ja auch...

So zumindest in meiner Theorie. Ob es der Apache so macht oder lieber neu parst, weiß ich nicht.

... dich bestätigt:

Es ist richtig, dass die Regeln nur einmal gelesen werden […]

Ich fand deine Darstellung nur verkürzt und habe sie deshalb ergänzt.

LG,
CK