PHP mod_rewrite Adressen richtig auflösen

Eagle-PsyX-

Commander
Registriert
Juni 2006
Beiträge
2.057
Hey,

ich ärgere mich schon änger über meine sporadisch implementiertes "unschönes" mod_rewrite und wollte das mal optisch versimplen und technisch verkomplizieren^^

Dabei geht es um die Darstellung von Links:
Aus aktuell http://webdesign.online-arts.de/category,1,design.html
sollte halt http://webdesign.online-arts.de/design/
und sowas wie http://webdesign.online-art.de/design/content,9,webseiten.htm
zu http://webdesign.online-art.de/design/webseiten.htm


Die hinter dem Front-End ein wesentliches komplexeres Back-End-System läuft wollte ich mal eure Meinung fragen, wie ich das am Besten und effizientesten Automatisieren sollten.

Eine Idee war bei jedem Eintrag, Löschen und Bearbeiten von Inhalt auf der Webseite eine MySQL-Tabelle zu führen mit dem groben Aufbau:
resolver
cat_id
con_id
gal_id
pic_id
design/1000
design/webseiten.htm1400
picture/cool.jpg0003
journey/last/7040

Beim duplizierten Namen wird erstmal falls Möglich auf die Art des Eintrages umgeschreiben z.B.: "category/design/" oder wenn das auch dupliziert vorkommt dann einfach durchgezählt "design-2/".

Zwar würde das klappen aber die Auflösung des URL müsste jedes Mal eine MySQL-Tabelle öffnen und eine Volltext-Suche in "resolver" durchführen. Auch wäre die Länge beschränkt je nachdem wie groß die Links sind. Alternativ vielleicht als Hash ablegen und danach Suchen? Damit wäre die Länge zumindest irrelevant. Aber dennoch, das absuchen bei über hundert Daten?

Ganz alternativ könnte ich auch einfach bei jeder Änderung die .htaccess-Datei überschreiben und klassiche rewrite-Regeln einfügen, wie das WCMS eigentlich schon bei unveröffentlichten Bildern/Dateien macht um den Zugang abzusperren. Dann hätte ich zwar irgendwann eine riesige .htaccess-Datei, müsste aber nicht mehr auf anstrengende Datenbanksuche ausflüchten.
Mag es aber weniger .htaccess zu generieren, da Fehler schnell im HTTP-Error-Code 505 enden können.

Was meint ihr dazu? Wie habt ihr solche Resolver realisiert?

Und bitte keine "manuelles Bearbeiten" der .htaccess-Datei vorschlagen, es sind z.T. hunderte Links die sich öfters ändern können und neue kommen immer dazu.

Ergänzung:
Da ich umfassende Statistik über Besucher im WCMS führe, wäre es auch problemlos möglich bei der Generierung der .htaccess-Datei die meist besuchten Webseiten als erste ReWrite-Regel aufzulisten. Somit erspare ich es bei jeder Abfrage statistisch alle Regeln in der Datei durchzugehen.
 
Zuletzt bearbeitet: (Ergänzung)
Mein Vorschlag:

In die .htaccess kommt folgendes:
Code:
RewriteRule .* index.php
Und im Code wird dann immer die URL per $_SERVER['REQUEST_URI'] ausgewertet und die Get-Parameter entsprechend gesetzt. Die hundert Wege, die .htaccess ständig synchron zu halten, ist doch viel zu aufwändig und fehleranfällig (Race Conditions seien nur mal so nebenbei erwähnt).
 
@Yuuri
Also das ist ja dann die erste Variante mit der MySQL-Tabelle.
Weil ich ja die GET-Parameter irgendwo absuchen und abgleichen muss.

Dass ich dann alle URLs zu einer Datei leite war mir bewusst ;-)
Race-Conditions sind möglichst umgangen, weil keine User gleichzeitig die selbe Datei/Content bearbeiten dürfen. Dafür bietet sich AJAX wunderbar an.

Bei der zweiten Variante könnte ich schlimmstens Falls die .htaccess über Nacht nur überschreiben lassen, somit sind Ausfälle sehr unwahrscheinlich.
 
Zuletzt bearbeitet:
Ich denke in PHP wirst da kaum andere Möglichkeiten haben. Evtl. die Tabelle nochmal im Dateisystem cachen, dann musst Du die allerdings jedes mal öffnen. Oder gibt es in PHP mittlerweile serverseitig einen Zustand für alle Zugriffe, wo man sowas evtl. einfach im Speicher halten kann?
 
@Drexel
Zumindest keiner mir geläufige. Dafür bietet sich die MySQL-Datenbank eigentlich immer an.
Die .htaccess-Datei wird sowieso bei jedem Öffnen abgefragt und ich glaube Apache-Serverseitig auch irgendwo gecacht.
 
Zuletzt bearbeitet:
Eagle-PsyX- schrieb:
Also das ist ja dann die erste Variante mit der MySQL-Tabelle.
Tabelle ja, nur komplett anders. Kommt natürlich auf deinen Aufbau drauf an, aber ohne irgendwas zu von deiner Seite zu wissen, würde ich einfach eine eigene Tabelle aufbauen und dort URL <-> Get-Parameter auflisten. Treffer -> Get-Parameter setzen, kein Treffer, normale Webseite zeigen (oder Weiterleitungen u.ä.).

Auf jeden Fall irgendwo eine Unique URL hinterlegen und nicht die URL jedes Mal neu parsen, außereinander nehmen, zurechtschnippeln und Parameter setzen.
Eagle-PsyX- schrieb:
Race-Conditions sind möglichst umgangen, weil keine User gleichzeitig die selbe Datei/Content bearbeiten dürfen. Dafür bietet sich AJAX wunderbar an.
Das kannst du nicht umgehen, außer du baust dir eine Queue mit einem Worker/Cron, der alles nacheinander in die .htaccess schreibt. Problem aber hierbei ist, dass es kurz zu Problemen beim Seitenaufruf kommen kann, wenn die .htaccess geschrieben wird und gleichzeitig ein Request geschieht.
Eagle-PsyX- schrieb:
Bei der zweiten Variante könnte ich schlimmstens Falls die .htaccess über Nacht nur überschreiben lassen, somit sind Ausfälle sehr unwahrscheinlich.
Nur hier sind aktuelle Änderungen evtl. erst 24 Stunden verfügbar.
Eagle-PsyX- schrieb:
Die .htaccess-Datei wird sowieso bei jedem Öffnen abgefragt und ich glaube Apache-Serverseitig auch irgendwo gecacht.
Die .htaccess wird nirgendwo gecacht, die wird bei jedem einzelnen Seitenaufruf durchgegangen (weswegen bspw. nginx komplett darauf verzichtet, da es u.U. Performanceprobleme geben kann). Dein Link beschreibt nur, wie man das Caching von ausgeliefertem Content in der .htaccess konfigurieren kann.
Eagle-PsyX- schrieb:
Zwar würde das klappen aber die Auflösung des URL müsste jedes Mal eine MySQL-Tabelle öffnen und eine Volltext-Suche in "resolver" durchführen. Auch wäre die Länge beschränkt je nachdem wie groß die Links sind. Alternativ vielleicht als Hash ablegen und danach Suchen? Damit wäre die Länge zumindest irrelevant. Aber dennoch, das absuchen bei über hundert Daten?
Volltextsuche? Eine URL ist einzigartig und am besten statisch. Da legst du einen paar Indices korrekt und gut ist. Optimalerweise liegt die DB eh im RAM und ist somit 100000000000000000x schneller als der Weg über die .htaccess.
 
@Yurri
Danke!
Jup, die Race Conditions wäre nie wirklich umgangen und die 24h wären auch blöd.

Werde wohl auf die Tabelle zurückgreifen. Beim obenen genannten Struktur-Beispiel ist "resolver" der URL und die Spalten rechts davon die die direkt interne ID auf den Inhalt. Die internen Links sind auch nur "?site=category&id=5", da reichen mir auch die IDs im Grunde.
Das könnte ich aber ausprobieren und schauen was im Endeffekt schneller ist (kurze Benchmarks mit 25'000 Einträgen).

Habe irgendwie nur gehofft es würde eine effizientere Methode geben.

P.S.: Habe den Link mir vorhin auch genauer angeschaut und deshalb wieder rausgenommen^^
Scheint wirklich gecacht zu werden.
 
Zuletzt bearbeitet:
Zurück
Oben