htaccess - mod_rewrite Konzept

[Sven Rautenberg]

Moin!

Das ist auch eine Verwaltungssache, es gibt ja auch statische
Inhalte, die die Endung .html tragen.

Ok. Ist natürlich sinnvoll, interne Gewohnheiten beizubehalten.

Eine ideale Lösung wäre meiner Meinung nach, wenn ich
schon in der htaccess das .html , falls eines in der URL steht,
durch ein .inc ersetzen könnte, also URL im Broser:

www.oldschool.de/pages/skate.html
Per 'Condition' wird aber /content/skate.inc abgefragt.

www.oldschool.de/pages/skate/
/content/skate/index.inc wird abgefragt.

Geht aber eher nicht, oder?

Klar geht das. Ist nur eine Winzigkeit komplizierter zu realisieren.

Du kannst ja in regulären Ausdrücken, also auch im Suchmuster der RewriteRule, Klammern setzen, um auf deren Inhalt später wieder zuzugreifen.

Du kannst in der RewriteCond auf die Klammerinhalte der RewriteRule zugreifen. Du kannst in der RewriteCond selbst auch wieder reguläre Ausdrücke haben, mit Klammern drin. Auf diese Klammern kannst du in anderen RewriteCond, und in der Ergebnisbildung der RewriteRule wieder zugreifen.

Du kannst also in der Summe ziemlich komplexe Transformationen machen, sie man im Endeffekt vermutlich nur noch als "krank" bezeichnen würde, und durch die fast niemand mehr durchblickt.

Aber so kompliziert ist es ja gar nicht.

Die Modifikation der bisherigen Lösung ist so: Du mußt irgendwie die URL-Endung ".html" vom Rest der URL isolieren. Diesen Teil setzt du in der RewriteCond anstatt der REQUEST_URI ein, und hängst noch ein ".inc" hinten dran, damit nachgesehen wird, ob eine inc-Datei auf dem Server existiert.

Dein PHP-Skript kriegt von der Incifizierung der URL zwar nichts mit, aber es dürfte leicht sein, mit Kenntnis der angeforderten URL den Pfad zur inc-Datei passend zu modifizieren.

Du kannst an dieser Stelle übrigens auch den Pfadteil "page" reinbringen. In der URL hat er nichts zu suchen - aber intern in deiner Verzeichnisstruktur vielleicht. Also kannst du ihn in der RewriteCond mit reinsetzen, damit in einem anderen Verzeichnis geprüft wird, als die URL, zusammen mit dem DOCUMENT_ROOT, vorgibt.

Statt

Virtuelle Struktur

# Alle Zugriffe auf / umleiten auf die Seitenauslieferung
 RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -s
 RewriteRule ^/.+.html$ /backoffice/page.php

also:

Virtuelle Struktur

# Alle Zugriffe auf / umleiten auf die Seitenauslieferung
 RewriteCond %{DOCUMENT_ROOT}/pages$1.inc -s
 RewriteRule ^(/.+).html$ /backoffice/page.php

Änderungen: Die Klammern in der RewriteRule sorgen dafür, dass man in den darüberstehenden RewriteCond (man kann ja mehr als eine haben) über $1 (weitere Klammern mit $2, $3 etc.) auf den gefundenen Inhalt zugreifen kann. Da ".html" dort nicht mit drinsteht, wird es in der RewriteCond einfach durch Anhängen von ".inc" ersetzt. Und auch das Verzeichnis "/pages" taucht dort auf, damit mod_rewrite im richtigen Verzeichnis die Existenz der Datei prüft.

Schau dir unbedingt die Doku-Seite von mod_rewrite an: http://httpd.apache.org/docs/mod/mod_rewrite.html. Da steht insbesondere drin, was man bei RewriteRule und RewriteCond so an Möglichkeiten zur Abfrage hat, und das Diagramm, welche Info wann wo durchfließt, ist auch von großem Nutzen.

Die Abwandlung habe ich nicht ausgetestet. Also keine Garantie, dass das direkt so funktioniert.

Warum ist das unlogisch? Beispiel: /page/shop.html ist die Erklärungsseite einer Agentur, dass sie auch Shops anbieten, und /page/shop/index.html ist die Startseite eines Demoshops.

Das würde ich nicht so machen, der Demoshop wäre dann im
Ordner 'demoshop', aber das war ja nur ein Beispiel und
wenn jamand anders am Projekt arbeitet, dann wird er es
u.U. nicht verstehen warum es nicht funktioniert, du hast recht.

Dann ist im Zweifel /page/demoshop.html die Erklärseite, wie man sich im Adminbereich des Demoshops anmeldet. :)

Naja, der Zeitdruck liegt eher an meiner Abschlussarbeit,
an der ich gerade arbeite, oldschool.de ist momentan Nebensache
und auf die Besucher in den paar Wochen kommt es mir weniger an,
alsauf meinen Perfektionismus, der mich nicht schlafen lässt...

Das ist eine gute Voraussetzung. Es macht keinen Sinn, schrittweise umzustellen. Entwickle und ändere alles auf einmal.

Auch deshalb bin ich gegen 404-Seiten mit Fehlermeldung,
ein Besucher der auf www.oldschool.de/skate/tricks/ollie.html
geht, kann immer noch auf www.oldschool.de/skate/tricks/
weitergeleitet werden, falls es die 1. Seite nicht gibt,
und wenn es die nicht gibt, dann halt auf www.oldschool.de/skate/

Ich finde es aber wichtig, den Besucher über das Nichtvorhandensein seiner gewünschten Ressource aufmerksam zu machen. Denn du weißt nichts über die Gründe, warum er einen 404-Fehler verursacht hat.

Kann ja sein, dass die Seite mal existierte, und jetzt weggekommen ist. Dann hat das Entfernen einen Grund. Wenn du von extern verlinkt wurdest mit den Worten "Super beschrieben ist es <link>hier</link>", und du hattest tatsächlich mal eine tolle Beschreibung von etwas, dann bringt es dem Besucher nichts, wenn er stattdessen auf eine Auflistung aller möglichen Beschreibungen oder einer thematischen Indexseite landet, wenn er doch viel lieber diese Beschreibung gelesen hätte.

404-Fehlerseiten machen klar, dass die gewünschte Seite nicht mehr verfügbar ist. Fertig. Aus die Maus. Wenn der fremde Verlinker mal einen Linkchecker über seine Site laufen läßt, wird der ihm ebenfalls anzeigen, dass sein Link auf die tolle Beschreibung leider tot ist.

Sofern du diese imaginäre Beschreibung nur auf eine andere Seite gesetzt hast, wäre es im Sinne ewig lebender URLs notwendig, einen individuellen Redirect auf die neue Seite zu setzen.

Das bedeutet unter dem Strich: Nichtexistierende Seiten haben grundsätzlich erstmal 404 zu sein. Die Fehlermeldung kann ja durchaus hilfreich sein und Links zu den existierenden, übergeordneten Seiten anbieten. Allein das Einbinden der Sitenavigation, mit der 404-Meldung als Content, ist oftmals schon ausreichend, vielleicht ergänzt um (aktuell auf Existenz geprüfte) Links zu den übergeordneten Informationsknoten.

Wenn eine Seite existiert hat, ist die so gültig gemachte URL auf ewig gesondert zu pflegen. Entweder wird die Seite erfolgreich ausgeliefert (Status 200), oder die Seite wird irgendwann mal unter einer anderen URL angeboten (Status 302 oder 301 als Redirect), oder die Seite wird irgendwann einmal wieder entfernt (Status 404 "not found" bzw. 410 "gone" - war da, ist es jetzt aber nicht mehr).

Allerdings indizieren die Suchmaschinen dann u.U. den content
doppelt und sehen das als Manipulierungsversuch an,
404-muss ich dann trotzdem ausgeben, naja vielleicht eine
Weiterleitung danach nach 0 sec. zum nächstnäheren Content.

Ich würde nichts weiterleiten. Der Benutzer hat ein Recht auf seine Fehlermeldung.

Stell dir vor, du bestellst in einer Kaffeebar einen "großen Schoko-Cappuchino mit Himbeersoße". Der Kellner nimmt die Bestellung entgegen, verschwindet hinter dem Tresen und macht. Und bringt dir schließlich eine Tasse mit Getränk darin. Nur ist das kein großer Schoko-Cappuchino mit Himbeersoße, sondern ein ganz normaler Kaffee, aber mit Vanillearoma. Himbeersoße war nicht mehr da, nur noch Vanillearoma, große Tassen sind im Geschirrspüler und waren noch nicht bereit, also nahm er eine normale Tasse, und die Capuchinomaschine ist gerade kaputt, also hat er einen Kaffee eingegossen und viel Milch dazugegeben.

Wärest du glücklich, wenn du für die im Vergleich zur Bestellung doch stark abweichende Lieferung auch noch bezahlen müßtest?

Wäre es nicht besser gewesen, der Kellner hätte dich informiert, dass deine Bestellung aus gewissen Gründen nicht ausführbar wäre, und dir vielleicht die möglichen Alternativen aufgezählt?

Ich spreche mich wirklich energisch gegen jede Art von automatischer Weiterleitung aus. Ich spreche mich genauso energisch für jede Art der Benutzerunterstützung in solch einem Fall aus. Aber die Form so einer Unterstützung kann eben sehr verschieden aussehen. Ein heiteres "URL-Raten" (so wie das Käse-Raten im Monty-Python-Sketch "Cheese Shop" - http://www.minderella.com/words/cheeseshop.htm) wird jedenfalls beim Besucher nicht stattfinden - und es sollte auch seitens des Servers nicht stattfinden.

- Sven Rautenberg