mod_rewrite - könnt ihr mir folgende Ausdrücke vereinfachen?

[fred]

Hi.
Ich würde gerne folgende 4 Ausdrücke zusammenfassen wenn es geht.
Wenn das nicht so effizient ist aber die unteren beiden genereller fassen.
Z.Z. habe ich die Möglichkeit 6 Parameter zu verwenden und für jeden weiteren würden die Ausdrücke noch länger werden. Kann man das nicht irgendwie kürzen und verallgemeinern?

wandelt www.example.com zu example.com um

RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

erlaubt schöne URLS zu nutzen example.com/A/B/C/D/E/F

RewriteRule ^/([a-zA-Z0-9-]+)/?([a-zA-Z0-9-]*)/?([a-zA-Z0-9-]*)/?([a-zA-Z0-9-]*)/?([a-zA-Z0-9-]*)/?([a-zA-Z0-9-]*)?$ index.php?p=$1&id=$2&a=$3&b=$4&c=$5&d=$6

erlaubt schöne URLS zu nutzen example.com/A/B/C/D/E/F/

RewriteRule ^([a-zA-Z0-9-]+)/?([a-zA-Z0-9-]*)/?([a-zA-Z0-9-]*)/?([a-zA-Z0-9-]*)/?([a-zA-Z0-9-]*)/?([a-zA-Z0-9-]*)/?$ index.php?p=$1&id=$2&a=$3&b=$4&c=$5&d=$6

Gruß, Fred

[Beat]

erlaubt schöne URLS zu nutzen example.com/A/B/C/D/E/F

Nicht maintainable!
Beauty gibt's nur mit the Beast.

mfg Beat

[Edgar Ehritt]

Hallo Fred,

RewriteRule ^/([a-zA-Z0-9-]+)/?([a-zA-Z0-9-]*)/?([a-zA-Z0-9-]*)/?([a-zA-Z0-9-]*)/?([a-zA-Z0-9-]*)/?([a-zA-Z0-9-]*)?$ index.php?p=$1&id=$2&a=$3&b=$4&c=$5&d=$6

Z.Z. habe ich die Möglichkeit 6 Parameter zu verwenden und für jeden weiteren würden die Ausdrücke noch länger werden. Kann man das nicht irgendwie kürzen und verallgemeinern?

man kann es nicht nur, man sollte es auch:

RewriteRule !^(index.php)$ index.php [L]

Das alleine ist für so viele Parameter (alias Verzeichnisse der URL) ausreichend, wie Du möchtest. Denn der ursprünglich aufgerufene Pfad kann in PHP über die Variable $_SERVER['REQUEST_URI'] mittelst explode() in die benötigten Parameter gegliedert werden.

Gruß aus Berlin!
eddi

[fred]

Hi.

RewriteRule !^(index.php)$ index.php [L]

Das alleine ist für so viele Parameter (alias Verzeichnisse der URL) ausreichend, wie Du möchtest. Denn der ursprünglich aufgerufene Pfad kann in PHP über die Variable $_SERVER['REQUEST_URI'] mittelst explode() in die benötigten Parameter gegliedert werden.

Danke aber man kann nun keine Stylesheets oder Scripte mehr einbinden.
/index.php
/Styles/s.css

ich habs probiert per:
Styles/s.css
/Styles/s.css
./Styles/s.css
/Styles/s

=/. Bitte hilf mir schnell.

Gruß, Fred

[Fred]

Edgar bitte..

ich hab jetzt 1000 Variationen probiert.
Bin jetzt hier hängen geblieben.
Aber es klappt nicht:
RewriteRule ^Styles/?([a-zA-Z0-9-]*)?$ Styles/$1.css [L]

[Fred]

Edgar bitte..

ich hab jetzt 1000 Variationen probiert.
Bin jetzt hier hängen geblieben.
Aber es klappt nicht:
RewriteRule ^Styles/?([a-zA-Z0-9-]*)?$ Styles/$1.css [L]

HAHA! YES, ich habs von selbst geschafft.
War für mich ganz schön schwer!
RewriteRule (Img|Scripts|Styles)/?([a-zA-Z0-9-.-_-]+).(png|js|css|ico)/?$ $1/$2.$3 [L,QSA]

Ist das in Ordnung so? Also funktionieren tut es :)

[Fred]

Aber..

Aber lohnt sich das vond er Performance her?
Ich meine Das alte waren auch nur zwei Rules aber sie waren doch eindeutiger als diese zwei:

RewriteRule (Img|Scripts|Styles)/?([a-zA-Z0-9-.-_-]+).(png|js|css|ico)/?$ $1/$2.$3 [L,QSA]
RewriteRule !^(index.php)$ index.php [L]

auch wenn diese "besser aussehen"..

[Edgar Ehritt]

Re:

Aber lohnt sich das vond er Performance her?

Da sind keine nennenswerten Effekte zu erwarten.

Ich meine Das alte waren auch nur zwei Rules aber sie waren doch eindeutiger als diese zwei:

RewriteRule (Img|Scripts|Styles)/?([a-zA-Z0-9-.-_-]+).(png|js|css|ico)/?$ $1/$2.$3 [L,QSA]
RewriteRule !^(index.php)$ index.php [L]

Hier würde bei einer vernünftigen Struktur des Webs ausreichen zu testen, ob die Zielressource kein Verzeichnis ist und tatsächlich nicht existiert. Dann wird auf index.php weitergeleitet:

RewriteEngine On  
RewriteCond   %{REQUEST_FILENAME}    !-d  
RewriteCond   %{REQUEST_FILENAME}    !-f  
RewriteRule   .*                     index.php [L]

Gruß aus Berlin!
eddi

[Fred]

Hey.

RewriteEngine On

RewriteCond   %{REQUEST_FILENAME}    !-d
RewriteCond   %{REQUEST_FILENAME}    !-f
RewriteRule   .*                     index.php [L]

Supi. Klasse, das funktioniert auch.  
  
Kannst du mal ein bisschen über die Performance reden? Wies da aussieht?

[Edgar Ehritt]

Re:

Kannst du mal ein bisschen über die Performance reden? Wies da aussieht?

Jede Servertechnik, die eine Erweiterung (Servermodule, CGI-Scripte, Datenbankanbindungen, etc.) der Funktionalität des Webserver bereitstellt, kostet. Diese Kosten sind zum einen mit der Hardware zutragen (CPU-Last, RAM, etc.), zum anderen mit der Geschwindigkeit, die zur Verarbeitung einer Anfrage benötigt wird. Dabei ist die Zeit meiner Erfahrung nach das kleinere Problem, was vielleicht auf den ersten Blick verdreht erscheint. Es ist tatsächlich nämlich nicht das Problem, ob eine Anfrage in 0,03 oder in 0,2 Sekunden bearbeitet wurde, da der Seitenbesucher nicht von der Servergeschwindigkeit abhängt. Er ist abhängig von der seines (DSL-)Anschlusses. Aller Wahrscheinlichkeit nach hat dieser, wenn er nicht google heißt, eine erheblich geringere Bandbreite als der Webserver. Vorderrangig ist also, ob der Server mit jeder Erweiterung durch größeren Verbrauch an Systemressourcen die Bandbreite mangels Leistung drosselt. Da ich Deine Hardware nicht kenne, gehe ich nur auf die Geschwindigkeit und die allgemeingültigen Konzepte ein. Es gibt etliche Ansätze, für Beschleunigung zu sorgen. Dazu lohnt es sich im einzelnen, _alle_ Komponenten, und was sie tun, zu betrachten. Schon mal vorweggenommen ist das Schielen _nur_ auf mod_rewrite garantiert der Falsche Weg. In Deinem Fall sind die Komponenten der Apache, mod_rewrite, PHP und das Webprojekt selbst:

Zum Apachen/Webserver:

Gerade beim Webserver finden sich die meisten möglichen Aspekte, Performance zu steigern, jedoch sind sie, in der Gesamtschau oftmals nachrangig. So kann man an seinem Server optimieren bis zum letzten gesparten Bit, was man mit einer CGI-Anwendung (CGI ist ein wirklich lahmes Interface) hintenrum wieder zunichte macht. Was kann man also alles machen? Zunächst einmal sich fragen, ob ich das richtige Produkt für mein Projekt habe. Apache ist nicht der schnellste Webserver. Das sollte man wissen. Beispielhaft sei hier nur auf lighttpd und nginx als Alternativen verwiesen.
 Kompression ist ein weiterer Aspekt, wenn der Datendurchsatz bei sehr vielen parallelen Anfragen gesteigert werden soll. Hierbei gilt mod_negotation mit vorkomprimierte Dateien serviert schneller und ressourcenschondender als mod_deflate oder PHP (zlib -> Ausgabekompression) und on-the-fly-compression.
 Dafür zu sorgen, dass Verbindungen ausreichend lange offen bleiben (Stichwort Keep-alive), kann für den Webnutzer sogar spürbar Geschwindigkeitsvorteile bringen. Hier kann ich aus eigener Erfahrung auch für den produktiven Einsatz mit Apache mod_event empfehlen.
 Das Erlauben von Verzeichnisweiter Konfiguration (.htaccess) ist eine große Geschwindigkeitsbremse.
 Andere Aspekte hat Christian Kruse in einem Artikel zusammengefasst.

Zu mod_rewrite:

RewriteEngine On

RewriteCond   %{REQUEST_FILENAME}    !-d
RewriteCond   %{REQUEST_FILENAME}    !-f
RewriteRule   .*                     index.php [L]

  
Das Modul ruft im ersten Fall (!-d) stat() auf, lässt also das System prüfen. Im zweiten Fall (!-f) wird wieder das System mit lstat() bemüht. In der Tat ist das nicht der performanteste Weg. Er ist aber überaus einfach und portabel. Wenn man die Verzeichnisstruktur seines Projektes genau kennt und sie sich nicht alle Nase lang ändert, ist es erheblich sinnvoller, auf die Verzeichnisnamen in einem Pattern zu testen, da, ohne es jetzt mit einem Benchmark belegen zu können, ein geringer Geschwindigkeitsvorteil zu erwarten sein sollte. Eine entsprechende Rewrite-Kondition könnte für Dich so aussehen:  
  
`RewriteCond   %{REQUEST_URI}    !^/(Img|Scripts|Styles)`{:.language-apache}  
  
  
Zu PHP:  
  
Betrachtungen der Performance sind fast ausschließlich hier relevant. Daher schrieb ich auch, dass bei mod\_rewrite keine nennenswerten Effekte zu erwarten seien. PHP kommt in der Gesamtbetrachtung die Rolle des Schwarzen Peters zu. Jede angeforderte Ressource, die nicht durch erst PHP generiert werden muss, wird schnell und systemschonend serviert. Man kann das immer wieder erneute Analysieren des Scriptcodes durch code-caching beschleunigen. Hier sei nur beispielhaft auf [eAccelerator](http://eaccelerator.net/), [APC](http://www.php.net/package/apc) und einen [Benchmark](http://2bits.com/articles/benchmarking-drupal-with-php-op-code-caches-apc-eaccelerator-and-xcache-compared.html) verwiesen.  
 Das PHP-Modul ist sehr viel schneller als PHP über CGI - und wenig schneller als PHP über FastCGI anzusprechen. Jedoch Vergrößert es auch die Arbeiterprozesse der Webserver erheblich, sodass eine Pauschale eigentlich nicht statthaft ist. In den überwiegenden Fällen wird man mit PHP als FastCGI-Applikation am besten fahren, obwohl es etwas langsamer ist. Die maximal verbrauchten Systemressourcen sind jedoch konfigurierbar und für Berechnungen relativ genau vorhersagbar.  
 Weiterhin sollte auch der Scriptcode optimiert werden. Das betrifft nicht so sehr Prozeduren und adäquate Code-Varianten als vielmehr strukturierte Programmierung an sich. Christian Seiler hatte das sehr gut [zusammengefasst](http://forum.de.selfhtml.org/archiv/2008/8/t175998/#m1157633), worauf es ankommen sollte. (Über die dortige Hetzjagt im Gesamtverlauf der Beiträge kann ich allerdings immer wieder nur den Kopf schütteln, was alles trotz Moderation in diesem Forum hier veranstaltet werden kann.)  
  
  
Zum Webprojekt:  
  
Generell werden statische Dokumente am schnellsten serviert. Wer also Geschwindigkeit, Bandbreite und Systemressourcen im Auge halten muss, macht sich von vornherein Gedanken, wie er sein Projekt strukturiert: Muss alles dynamisch generiert werden, was die Performance beeinträchtigt? Wie kann ich oben angesprochene Kompression vielleicht nutzen? Dazu will ich nur auf andere [Beiträge im Archiv](http://forum.de.selfhtml.org/archiv/2009/6/t188297/#m1253164) verweisen, die das Thema sehr ausführlich behandeln. Anzumerken bleibt, dass man das Servieren durch Auslagerung des Projektes in den Arbeitsspeicher (Stichwort ramfs) nochmals etwas beschleunigen kann. Dies betrifft prinzipiell auch Datenbanken.  
  
  
Gruß aus Berlin!  
eddi