Mode Rewrite und: Ein Script für Alles?

[hotti]

Liebe Mitstreiter,

so nach und nach entdecke ich Mode_Rewrite und die bisher ungeahnten Möglichkeiten, damit mächtig, gewaltig URLs umzubiegen. Und so hab ich bisher zwei Scripts an die Front geschossen

.html => view.cgi
.jpg  => img.cgi

jetzt will ich noch verschiedene Sitemaps machen und den Aufruf der robots.txt in meiner Datenbank loggen. Da wirds doch langsam Zeit mal drüber nachzudenken, ob das nicht alles mit _einem_ Script erledigt werden kann, was dazu parametergesteuert ist.

Wollte nur mal fragen, ob Ihr das auch so macht, oder so.

Hotti

[Gustav]

Hallo Hotti!

Ich habe genau dasselbe vor, wenn auch nur in kleinem Maßstab.
Leider habe ich die Rewrite-Regeln (in der .htaccess-Datei) noch nicht richtig hinbekommen.

Wie sehen die Rewrite-Regeln aus, um alle .html => view.cgi umzubiegen? Das wäre schon eine große Hilfe für mich. =)

Grüße
Gustav

[hotti]

hi Gustav,

Wie sehen die Rewrite-Regeln aus, um alle .html => view.cgi umzubiegen? Das wäre schon eine große Hilfe für mich. =)

So siehts bei mir derzeit aus:
RewriteEngine on
RewriteRule ^(.*).html$ /cgi-bin/view.cgi?/$1.html

RewriteRule ^(.*).jpg$ /cgi-bin/imgred.cgi?jpeg
RewriteRule ^(.*).gif$ /cgi-bin/imgred.cgi?gif

Neu wirds so sein:
RewriteRule ^(.*).html$ /cgi-bin/show.cgi?type=html
RewriteRule ^(.*).jpg$ /cgi-bin/show.cgi?type=jpeg
RewriteRule ^(.*).gif$ /cgi-bin/show.cgi?type=gif
RewriteRule ^robots.txt /cgi-bin/show.cgi?type=text;file=robots.txt
RewriteRule ^sitemap.xml /cgi-bin/show.cgi?type=xml;file=sitemap

show.cgi ist bei mir in Perl, gibt den gewünschten Content-type aus und die Datei(en). Loggt, wenn es sein muss und nimmt alles, was so gebraucht wird aus der CGI-Umgebung %ENV, z.B. den REQUEST_URI. show.cgi kann auch RSS-Feeds generieren.

Hotte

[Gustav]

Hallo!

Toll! So ein Beispiel bringt mich zumindest immer viel schneller weiter, als die Hilfedateien ohne Beispiele.
Vielen Dank!

Heute werde ich nicht mehr dazu kommen, aber in den nächsten Tagen sicherlich.

Grüße
Gustav

[hotti]

hi,

Toll! So ein Beispiel bringt mich zumindest immer viel schneller weiter, als die Hilfedateien ohne Beispiele.

Noch mal eine der Regeln bei mir
RewriteRule ^(.*).html$ /cgi-bin/view.cgi?/$1.html

-> der Klammerausdruck hat den Namen der Datei, der wird an das Script über den QUERY_STRING übergeben. Mein Gedanke ist nun

1. den Dateinamen finde ich auch in $ENV{REQUEST_URI}, die bisherige Übergabe kann also entfallen
2. weitere Informationen, die das Script braucht, werden als Parameter key=value Paare übergeben und in der .htaccess fest codiert (geschrieben).

Somit hat der QUERY_STRING nicht nur eine Info, sondern mehrere, die ganz einfach mit CGI 'param' geparst werden und im Script eine Kontrollstruktur durchmachen. Dort wird dann entschieden, wie die Response aussieht.

Der Haken an der ganzen Sache ist nur der, dass ich bei _einem_ Script ein bischen mehr nachdenken muss wegen der Kontrollstruktur damit da nichts in die Hose geht ;-)

Viele Grüße,
Horst Haselhuhn

[Tom]

Hello Hotti,

so nach und nach entdecke ich Mode_Rewrite und die bisher ungeahnten Möglichkeiten, damit mächtig, gewaltig URLs umzubiegen. Und so hab ich bisher zwei Scripts an die Front geschossen

Denke immer daran, dass eine vollständige Nutzung des Rewrite-Moduls eine bidirektionale Schnittstelle darstellen sollte und daher auch eine bidirektionale Transformation erforderlich macht.

Jeder Request, der von außen von /param1/param2/param3/param4 auf ein (oder mehrere) Script(e) mit den entsprechenden Parametern umgeleitet wird, muss in den Scripten auch Links nach demselben Schema erzeugen.

Das heißt auf Deutsch:

1. Du brauchst eine Schnittstellenbeschreibung, die
2. von allen Requests genutzt werden kann
3. von allen responses genutzt werden kann.

Andere Lösungen sind in meinen Augen relativ sinnfrei.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

hi Tom,

Jeder Request, der von außen von /param1/param2/param3/param4 auf ein (oder mehrere) Script(e) mit den entsprechenden Parametern umgeleitet wird, muss in den Scripten auch Links nach demselben Schema erzeugen.

Das heißt auf Deutsch:

1. Du brauchst eine Schnittstellenbeschreibung, die
2. von allen Requests genutzt werden kann
3. von allen responses genutzt werden kann.

Mist, das hab ich jetzt nicht kapiert. Bitte erklärs mir, evntl. mit einem klitzekleinen Beispiel.

Viele Grüße,
Hotti

[Der Martin]

Hallo,

1. Du brauchst eine Schnittstellenbeschreibung, die
2. von allen Requests genutzt werden kann
3. von allen responses genutzt werden kann.
   Mist, das hab ich jetzt nicht kapiert. Bitte erklärs mir, evntl. mit einem klitzekleinen Beispiel.

das ist ganz einfach: Wenn du URLs umschreibst, so dass /kategorie/produkt/specs auf /index.php?kat=kategorie&prod=produkt&section=Specs landet, dann muss die index.php auch diesen Mechanismus rückwärts gehen können, damit sie Links erzeugen kann, die mit eben dieser Rewrite Rule wieder "funktionieren".
Solange das Projekt überschaubar ist, kann man diesen Weg natürlich "zu Fuß" gehen und die Links gleich passend zu dem nach außen vorgetäuschten URL-Gefüge notieren. Ab einer gewissen Komplexität wird das aber schwierig.

Ciao,
 Martin

[hotti]

hi,

das ist ganz einfach: Wenn du URLs umschreibst, so dass /kategorie/produkt/specs auf /index.php?kat=kategorie&prod=produkt&section=Specs landet, dann muss die index.php auch diesen Mechanismus rückwärts gehen können, damit sie Links erzeugen kann, die mit eben dieser Rewrite Rule wieder "funktionieren".

Ich wär noch blöd, "stehe auf dem Schlauch", wie: Links erzeugen? Was sind Links?

Solange das Projekt überschaubar ist, kann man diesen Weg natürlich "zu Fuß" gehen und die Links gleich passend zu dem nach außen vorgetäuschten URL-Gefüge notieren. Ab einer gewissen Komplexität wird das aber schwierig.

Also ich habe:
RewriteRule ^(.*).html$ /cgi-bin/view.cgi

und seit ner halben Stunde eine neue Regel
RewriteRule ^robots.txt$ /cgi-bin/filer.cgi?robots=1

Was ist jetzt in diesem Zusammenhang ein "Link" ????

Hotte

[Tom]

Hello,

Was ist jetzt in diesem Zusammenhang ein "Link" ????

Das, was Du übersehen hast, für das Gesamtkunstwerk.

Per REQUEST kommt diem Anforderung für eine bestimmte Ressource, die aber im Projakt gar nicht als statische Ressource vorhanden ist, sondern in der Datenbank versteckt auf ihre Erweckung per

index.php/show=liste;section=clients;start=adam;stop=eva

wartet. Nun kannst Du die URL auf diese Parmeter umbiegen und alles wird gut.

In der Response steckt jetzt aber auch noch eine "Anleitung für den Client", was er denn als nächstes anfordern könnte. Diese "Anleitung" wird drich eine Liste von Links geliefert, die nun natürlich nicht den URi-Paramtererstring enthalten sollen, sondern eben die URL-Form mit Path-Info, aber auf jeden Fall ohne Parameter...

Dein Controller muss also wissen, wie er durch Abgleich von Model und "Rewrite-Rückwärts-Anweisung" aus der Datenbankabfrage wieder eine gefakte (per mod rewrite auflösbare) URL macht.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

hmmm,

In der Response steckt jetzt aber auch noch eine "Anleitung für den Client", was er denn als nächstes anfordern könnte. Diese "Anleitung" wird drich eine Liste von Links geliefert, die nun natürlich nicht den URi-Paramtererstring enthalten sollen, sondern eben die URL-Form mit Path-Info, aber auf jeden Fall ohne Parameter...

eine meiner mit modRewrite ausgelieferten Seiten:

Hier sind keine Links drin.

Falls jemand die robots.txt anfordert, da sind auch keine Links drin.
Und last but not least, in meinen GIFs sind auch keine Links drin.

Was mache ich falsch?

Viele Grüße,
Horst

[Tom]

Hello,

Was mache ich falsch?

Das, was Du auslieferst, gehört nicht ins Internet, sondern in (gute) Bücher.
Das Internet ist ein Dialogsystem und sollte auch intensiv als solches genutzt werden.

[Den obligatorischen (Ab-)Satz mit Uschi und Wolle verkneife ich mir jetzt]

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

ok,

Das Internet ist ein Dialogsystem und sollte auch intensiv als solches genutzt werden.

Das hab ich beim Fernsehen früher auch gedacht, dass die Berghoff Dagmar in mich verknallt ist und bei Heinz Schenk bin ich immer hinters Sofa gekrochen, weil ich Angst hatte, der holt mich auf die Bühne zum Bembeln.

S' spät geworden, morgen packnmers wieder ;-)

Wenn ich mal wieder im Harz bin, ziehe ich Lederhosen an und springe über ein Sonnenwendfeuer.

Viele Grüße,
Hotte

PS: In Zorge gibts ein sehr schönes Freibad.

[Tom]

Hello,

Wenn ich mal wieder im Harz bin, ziehe ich Lederhosen an und springe über ein Sonnenwendfeuer.

Klasse. Dann klebe ich Dir den JAC1-Aufkleber mit "I'am just a tourist" hinten drauf :-)

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

moin,

Das, was Du auslieferst, gehört nicht ins Internet, sondern in (gute) Bücher.

Danke Tom!

Ich bin ja schon dran am Schreiben, den meisten Stoff dazu liefert mir dieses Forum, was hier so steht, finde ich auf keiner Müllhalde.

Viele Grüße,
Horst Haselhuhn

[hotti]

moin,

das ist ganz einfach: Wenn du URLs umschreibst, so dass /kategorie/produkt/specs auf /index.php?kat=kategorie&prod=produkt&section=Specs landet, dann muss die index.php auch diesen Mechanismus rückwärts gehen können, damit sie Links erzeugen kann, die mit eben dieser Rewrite Rule wieder "funktionieren".

Eine Parametrisierung der REQUEST_URI kann ich machen, muss aber nicht.

Um bei Deinem Beispiel zu bleiben, der User requestet

http://example.com/kategorie/produkt/specs

REQUEST_URI ist eine Variable in der Serverumgebung, da steht in diesem Fall drin:

/kategorie/produkt/specs

Das Perl-Script findet diesen String in $ENV{REQUEST_URI}. Habe ich diesen String als Primary-Key in meiner Datenbank, wird das Perl-Script den Content dazu ausliefern. Wenn nicht in DB, wird das Script eine andere nette Antwort geben, ggf. mit einem HTTP "Status: 410 Gone" vornedran.

Will ich jedoch meine Idee von gestern umsetzen, also mit _einem_ Script mehrere RewriteRules umsetzen, muss ich dem Script mitteilen, welche Rule es zu bedienen hat. Nur dazu brauche ich einen oder mehrere Parameter. Ja, ich meine, einer reicht schon:

... /rewrite_handle.cgi?rule=1
... /rewrite_handle.cgi?rule=2
... /rewrite_handle.cgi?rule=3

Damit hat das Script alles, was es braucht um seiner Funktion gerecht zu werden.

Viele Grüße,
Horst Haselhuhn

[Gunther]

Hallo Martin!

Solange das Projekt überschaubar ist, kann man diesen Weg natürlich "zu Fuß" gehen und die Links gleich passend zu dem nach außen vorgetäuschten URL-Gefüge notieren. Ab einer gewissen Komplexität wird das aber schwierig.

FACK.
Aber wie macht man das denn dann z.B. per Script? Die "Nachbildung" oder Umsetzung einer für Menschen einfachen Logik kann ja schnell sehr kompliziert & umfangreich werden.

Bietet sich hier ggf. als Zwischenschritt/ Mittelweg auch erstmal eine reine (Nachschlage-/ Übersetzungs-)Tabelle an (solange die Zahl an Links nicht zu groß wird).

Gruß Gunther

[Tom]

Hello,

Aber wie macht man das denn dann z.B. per Script? Die "Nachbildung" oder Umsetzung einer für Menschen einfachen Logik kann ja schnell sehr kompliziert & umfangreich werden.

Beim Request werden Positionsparameter umgewandelt in Optionsparameter, also solche mit Namen.

Das angesprochene Script muss nun nur wissen, an welcher Position welcher Parameter später wieder stehen muss und dessen Wert dann beim Aufbau von URLs einsetzen.

Wenn hinter dem Mod-Rewrite ohnehin ein Script angesprochen wird, kann man sich diesen also eigentlich schon fast schenken, denn dann kann das kontrollierende Script die Path-Info auch gleich selber auswerten.

Man braucht den Rewrite-Mode dann eigentlich nur dafür, dass das richgtige Script angesprochen wird.

Die weitere URL muss eigentlich gar nicht mehr umgeschrieben werden.

Ich habe mir heute ein Projekt angeschaut, in dem doch tatsächlich ca. 120 Zeilen Rewrite-Regeln benutzt werden, nur weil die URis, also jene mit Parametern, angeblich suchmaschinenfeindlich sind...

So ein Projekt zu bearbeiten macht jedenfalls keinen großen Spaß. Man muss bei Requests immer erst URL-Raten spielen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Gunther]

Hello Tom,

Wenn hinter dem Mod-Rewrite ohnehin ein Script angesprochen wird, kann man sich diesen also eigentlich schon fast schenken, denn dann kann das kontrollierende Script die Path-Info auch gleich selber auswerten.

Ja, sehe ich auch so. Wobei es imho dann prinzipiell noch zwei Verfahrensweisen gibt:
1. Das aufgerufene Script wertet die Path-Info aus und leitet dann dementsprechend per Location Header weiter auf eine andere Datei.
2. Das ausgerufene Script "baut" die entsprechende Seite direkt (per Includes) zusammen.

Man braucht den Rewrite-Mode dann eigentlich nur dafür, dass das richgtige Script angesprochen wird.

Die weitere URL muss eigentlich gar nicht mehr umgeschrieben werden.

Welche "weitere URL"?
Es muss doch nur solange sichtbar redirected werden, bis die "gewünschte/ richtige" URL in der Adresszeile steht (und dann natürlich noch unsichtbar auf die Script Datei).

Ich habe mir heute ein Projekt angeschaut, in dem doch tatsächlich ca. 120 Zeilen Rewrite-Regeln benutzt werden, nur weil die URis, also jene mit Parametern, angeblich suchmaschinenfeindlich sind...

Das ist imho ja nicht der wesentliche Punkt dabei. Wesentlicher finde ich den Punkt, dass sie nicht benutzerfreundlich (gut menschenlesbar) sind.

So ein Projekt zu bearbeiten macht jedenfalls keinen großen Spaß. Man muss bei Requests immer erst URL-Raten spielen.

Das ist imho zum einen nicht wartungsfreundlich und zum anderen auch sehr fehleranfällig, was ich auch als eines der größten Probleme von mod_rewrite ansehe. Denn eine einzige Änderung kann schon ausreichen, dass die anderen 120 Zeilen nicht mehr wie gewünscht funktionieren.

Jetzt weiß ich aber immer noch nicht, wie_du_z.B. eine sriptseitige Umwandlung vornehmen würdest? Wobei sich mir ja die Frage stellt, inwieweit eine Rück-Umwandlung überhaupt erforderlich ist? Wenn das Script für die Ausgabe doch direkt die "sprechenden" Links erzeugt, ist das doch gar nicht von Nöten, oder?
(Kann aber auch sein, dass ich etwas "überhitzt" bin, bei den knapp 30° Grad im Schatten und gefühlten 95% Luftfeuchtigkeit!)

Gruß Gunther

[hotti]

Sorry,

Wenn hinter dem Mod-Rewrite ohnehin ein Script angesprochen wird, kann man sich diesen also eigentlich schon fast schenken, denn dann kann das kontrollierende Script die Path-Info auch gleich selber auswerten.
Ja, sehe ich auch so. Wobei es imho dann prinzipiell noch zwei Verfahrensweisen gibt:

1. Das aufgerufene Script wertet die Path-Info aus und leitet dann dementsprechend per Location Header weiter auf eine andere Datei.
2. Das ausgerufene Script "baut" die entsprechende Seite direkt (per Includes) zusammen.

1. würde eine Endlosschleife geben

*.html -> rewrite -> script -> umleitung -> *.html -|
^---------------------------------------------------|

Das würde auch die Suchmaschinen etwas verwirren.

2. das Script muss eine Source für den Content haben, der kann im FS liegen oder in einer DB oder sonstwo, auf jeden Fall da wo's abholen nicht lange dauert.

Hotti

[Gunther]

Hi,

Wenn hinter dem Mod-Rewrite ohnehin ein Script angesprochen wird, kann man sich diesen also eigentlich schon fast schenken, denn dann kann das kontrollierende Script die Path-Info auch gleich selber auswerten.
Ja, sehe ich auch so. Wobei es imho dann prinzipiell noch zwei Verfahrensweisen gibt:

1. Das aufgerufene Script wertet die Path-Info aus und leitet dann dementsprechend per Location Header weiter auf eine andere Datei.
2. Das ausgerufene Script "baut" die entsprechende Seite direkt (per Includes) zusammen.

1. würde eine Endlosschleife geben

*.html -> rewrite -> script -> umleitung -> *.html -|
^---------------------------------------------------|

Warum?
Es könnte bspw. auf ein Unterverzeichnis weitergeleitet werden, wo kein Rewrite stattfindet oder du hast u.a. eine Rewrite Condition wie 'RewriteCond %{REQUEST_FILENAME} !-f' und/ oder 'RewriteCond %{REQUEST_FILENAME} !-d'.

Gruß Gunther

[hotti]

hi Gunther,

Es könnte bspw. auf ein Unterverzeichnis weitergeleitet werden, wo kein Rewrite stattfindet oder du hast u.a. eine Rewrite Condition wie 'RewriteCond %{REQUEST_FILENAME} !-f' und/ oder 'RewriteCond %{REQUEST_FILENAME} !-d'.

Freilich, das geht. Trotz Hitze frag ich mich da jedoch, warum ein Rewrite und obendrein noch ne Umleitung wenn am Ziel eine HTML-Source liegt, die damit unverändert in die Response geht.

Hotte

[Gunther]

Hi Hotte!

Freilich, das geht. Trotz Hitze frag ich mich da jedoch, warum ein Rewrite und obendrein noch ne Umleitung wenn am Ziel eine HTML-Source liegt, die damit unverändert in die Response geht.

Wenn man eine (statische) HTML-Source hat, gebe ich dir Recht, dass das dann keinen Sinn macht. Aber i.d.R. reden wir hierbei ja von dynamischen Seiten, die "zusammengebaut" werden.

Gruß Gunther

[hotti]

hi,

Freilich, das geht. Trotz Hitze frag ich mich da jedoch, warum ein Rewrite und obendrein noch ne Umleitung wenn am Ziel eine HTML-Source liegt, die damit unverändert in die Response geht.
Wenn man eine (statische) HTML-Source hat, gebe ich dir Recht, dass das dann keinen Sinn macht. Aber i.d.R. reden wir hierbei ja von dynamischen Seiten, die "zusammengebaut" werden.

Ja Klar Gunther. Sinnvollerweise so, dass es _eine_ RewriteRule für *.html gibt und das aktive Script anhand der Requesteten URL alles Weitere in die Seite einbaut.

Alles "Weitere" das ist mindestens ein aussagekräftiger Titel für die Datei, eine Beschreibung (description im meta-Tag), die Zugehörigkeit zu welchem Ordner die Datei gehört und der Content selbst. Optional sind Erstellungsdatum, Autor u.a. Und anhand der Ordnerzugehörigkeit ergibt sich das Navigationsmenu für jede ausgelieferte HTML-Seite.

So habe ich Rewrite nicht nur verstanden sondern auch umgesetzt.

Viele Grüße,
Horst Haselhuhn

[hotti]

Ich habe mir heute ein Projekt angeschaut, in dem doch tatsächlich ca. 120 Zeilen Rewrite-Regeln benutzt werden, nur weil die URis, also jene mit Parametern, angeblich suchmaschinenfeindlich sind...

Hi Tom,

also wer für jede URL eine RewriteRule schreibt, hat mod_rewrite schlicht und einfach nicht verstanden.

Bei mir sind es nun ganze 4 Regeln:
DirectoryIndex /cgi-bin/show.cgi?html

RewriteEngine on
RewriteRule ^(.*).html$ /cgi-bin/show.cgi?html

RewriteRule ^(.*).jpg$ /cgi-bin/show.cgi?jpeg
RewriteRule ^(.*).gif$ /cgi-bin/show.cgi?gif

RewriteRule ^robots.txt$ /cgi-bin/show.cgi?robots

Und weil ich da so nebenbei die robots.txt auch noch automatisiere, macht show.cgi gleich den Sitemap, vorerst als rss+xml

  
###########################################################################  
# zeige die Datei robots.txt  
sub robots{  
	print "Content-type: text/plain\n\n";  
	print qq(  
#  
# robots.txt file for http://rolfrost.de  
#  
  
Sitemap: http://rolfrost.de/cgi-bin/rssfeed.cgi  
Sitemap: http://rolfrost.de$ENV{SCRIPT_NAME}?rss  
  
  
Disallow: /Extern.html  
  
# ende  
);  
  
	# den Zugriff loggen, vorerst in die Mailbox  
	my $date = strftime("%d.%m.%Y %X", localtime(time));  
  
my $log = qq(robots.txt  
DT: $date  
IP: $ENV{REMOTE_ADDR}  
UA: $ENV{HTTP_USER_AGENT}  
);	  
	$dbh->do("INSERT INTO mailbox VALUES('', '$log')");  
  
	return;  
}  
###########################################################################  

Demnächst darf ich wieder ein paar Scripts auf dem Server löschen ;-)

Viele Grüße,
Hotti

[Sven Rautenberg]

Moin!

also wer für jede URL eine RewriteRule schreibt, hat mod_rewrite schlicht und einfach nicht verstanden.

Und wer für eine Regel vier Regeln schreibt, auch irgendwie.

Bei mir sind es nun ganze 4 Regeln:
DirectoryIndex /cgi-bin/show.cgi?html

RewriteEngine on
RewriteRule ^(.*).html$ /cgi-bin/show.cgi?html

RewriteRule ^(.*).jpg$ /cgi-bin/show.cgi?jpeg
RewriteRule ^(.*).gif$ /cgi-bin/show.cgi?gif

RewriteRule ^robots.txt$ /cgi-bin/show.cgi?robots

Alle Requests gehen zu /cgi-bin/show.cgi - und das arbeitet dann mit der REQUEST_URI. Warum differenziert die RewriteRule dann noch Sonderfälle durch Spezifikation eines Querystrings, welches gleichzeitig (da kein [QSA] angegeben) eventuelle Query-Strings an der Original-URL entfernt.

- Sven Rautenberg

[hotti]

Moin Sven,

Alle Requests gehen zu /cgi-bin/show.cgi - und das arbeitet dann mit der REQUEST_URI. Warum differenziert die RewriteRule dann noch Sonderfälle durch Spezifikation eines Querystrings, welches gleichzeitig (da kein [QSA] angegeben) eventuelle Query-Strings an der Original-URL entfernt.

Danke für den Denkanstoß!!

QUERY_STRING's werden nicht entfernt. Die gibt es weiterhin bei meinen CGI's. Die CGI's sind auch der Grund, warum ich nicht _alle_ REQUEST_URI's auf den Rewrite_handle umschreiben kann. Hmm, mal angenommen, die CGI's ausgenommen.

Also, _eine_ Regel, die alles (jpg,gif,html,txt) außer *.cgi auf show.cgi umschreibt.

Klar, das geht, Sven, wenn: Ich meine Projektverwaltung verbessere/erweitere. Best Practice ist es, hier anzusetzen!

Zu verwalten sind URLs, die publiziert werden sollen. Bisher habe ich in meiner Verwaltung zu jeder URL:

title, content, description, folder

Hinzukommen müsste nun noch der Content-type, wenn ich den auch noch habe, kann ich in der RewriteRule auf den QUERY_STRING verzichten und brauche nur noch eine einzige Regel.

Das wird ne geile Tabelle :-)

title, content, description, folder, charset, content_type, pudate

evntl. noch ein flag, in dem steht _wo_ der content zu finden ist, das kann in der DB sein oder im Dateisystem.

Na, ich werde das mal überschlafen.... Wenn Du noch ne Idee hierzu hast, lass sie hier fallen.

Viele Grüße,
Horst