htaccess - mod_rewrite Konzept

[Sven Rautenberg]

Moin!

Tu dir selbst einen Gefallen und nimm vernünftige URLs.
/about_links.html
/skate/history/index.html

Mit dem .html habe ich ein Problem, unter .html verstehe
ich vollwertige HTML-Seiten (mit doctype & co), daher
habe ich den dateinamen .inc gewählt - das funktioniert
dann in der URL natürlich nicht.

Das Problem ist aber ja nur höchst ansichts- und gefühlshalber. Also kein echter Grund.

Ich habe als HTML-Dateien zwar welche mit echtem DOCTYPE etc., aber das sind Templates, die vom Skript noch ausgefüllt werden müssen. Außerdem kann man sich in einzelnen Verzeichnissen beliebige Freiheitsgrade mit mod_rewrite konfigurieren. Beispielsweise die gesamte Produktpalette eines Shops über eine Gruppe vernünftiger URLs auf das Anzeigeskript mappen, welches dann lediglich _eine_ Templatevorlage lädt und z.B. die Artikelnummer aus der URL entnimmt - wohlgemerkt nicht aus irgendeinem Parameter, der "artnr" oder so heißt.

Warum /page/ da reinfriemeln? Ist überflüssig und bringt der URL nichts, macht sie nur unnötig lang. Es sei denn, du hast einen strukturbedingten, guten Grund, "Seiten" in ein Verzeichnis "page" zu pflanzen.

Wieder so ein Konflikt, der URL schadet's, aber meine
Ornderstruktur wird dadurch übersichtlicher, naja, das
ist ja erstmal nebensächlich.

Deiner _jetzigen_ Struktur schadet es vielleicht. Wenn du sämtliche Anzeigeskripte in ein entsprechendes Verzeichnis packst, hast du im Hauptverzeichnis viel Platz für den Content.

Es ist im Prinzip egal, ob du nun alles in "/pages/" drinstehen hast, oder in "/".

Der Fall wird nicht eintreten, da ich keine gleichnamige Datei
unterhalb eines Verzeichnisses einbinden werde, ist ja auch unlogisch: wenn ich eine Datei page/shop/index.inc habe, dann ist
die Datei page/shop.inc ja überflüssig. Mit den Suchmaschinen bist Du Dir sicher?

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.

Finde ich sehr logisch. Es wäre unklug, diese Beschränkung einfach nur wegen der Beschränkung machen zu wollen. Wenn du programmtechnisch daraus irgendeinen Vorteil ziehen könntest, dann könnte ich es verstehen. Sowas sehe ich aber nicht.

Die Suchmaschinen nehmen nur die Links, die sie als href auf deiner Seite finden. Wenn dort Slashes am Ende sind, wird der entsprechende Link genommen. Wenn da keine sind, wird ohne Slash gearbeitet. Wenn dein Webserver eine Anforderung nach einer URL ohne Slash redirectet in eine URL mit Slash (wenn du auf ein Verzeichnis gelinkt hast, ohne dass du am Ende einen Slash gemacht hast), dann wird das die Suchmaschine unter Umständen beeinflussen, und sie wird die URL mit Slash indizieren. Ist ja auch sinnvoll, weil exakt diese URL den Content übermittelt hat.

Obwohl,
werden die Pfade innerhalb der css von allen Browsern
von dieser ausgehend gewertet? Bin gerade etwas verwirrt.

Nein. Alle Browser bis auf Netscape 4 gehen bei der URL-Bildung in einer externen CSS-Datei von der URL-Position der CSS-Datei aus. Das ist sinnvoll.

Netscape 4 geht bei der URL-Bildung in einer externen CSS-Datei von der URL-Position der anzuzeigenden Seite aus. Das ist meistens böse, weil man bei unterschiedlichen Verzeichnistiefen praktisch keine vernünftige relative Adressierung vornehmen kann. Absolute Adressierung ist notwendig. Nur in ganz wenigen theoretischen Anwendungsfällen ist dieses Verhalten des NS4 irgendwie sinnvoll. Beispielsweise, um je nach Verzeichnis andere Bilder mit CSS einzubinden, z.B. einen anderen Hintergrund.

wichtig ist ersteinmal die Navigation, damit die wichtigsten Seiten
indiziert werden. Habe schon an eine robots.txt gedacht,
da bin ich mir aber auch nicht sicher ob die Suchmaschinen
dann die Parameter in der URL akzeptieren würden.

Eine robots.txt sagt vernünftigen Suchmaschinen, welche Verzeichnisse auf dem Server sie NICHT indizieren sollen. Willst du Bereiche ausschließen, mußt du die da reinschreiben. Willst du keine Bereiche ausschließen, lass sie weg. Willst du die dummen 404-Fehler vermeiden, lege eine leere Datei an.

Was die Umstellung angeht: Entweder ganz, oder gar nicht, würde ich sagen. Logisch, dass du da vielleicht etwas unter Zeitdruck stehst, weil demnächst ja schon wieder eine Suchmaschine reinschauen könnte. Das tun sie nach meiner Erfahrung aber andauernd, und lesen immer mal wieder eine neue Seite ein.

Was du bei der Umstellung keinesfalls vergessen solltest: Permanente Redirects zumindest von den wichtigsten in den Suchmaschinen vertretenen URLs zu deinen neuen Seiten anlegen. Eine Suchmaschine ändert dann vielleicht schneller ihren Index und aktualisiert ihre Fundergebnisse. Außerdem kriegt ein Besucher mit einem alten Suchergebnis dann immerhin eine vernünftige Seite, und keinen Fehler.

Das leitet _alle_ Requests, die auf ".html" enden, auf das Seitenauslieferungsskript um. Die RewriteCond prüft, ob im Verzeichnisbaum eine entsprechende Datei tatsächlich existiert.

Die Condition brauche ich ja dann auch eigentlich nicht, oder (?),
denn wenn eine Seite nicht existiert, dann zeige ich doch
lieber die Startseite an, oder das nächste existierende
Unterverzeichniss, als ein 404 auszugeben, auch wenn
ein 404 ja auch auf die Startseite verweisen kann.

Nein. Wenn bei dir alle URLs gültig sind, und auf allen Seiten immer die Startseite angezeigt wird, ist das eher schlecht.

Eine nicht gefundene Seite, basierend auf der Definition dessen, was du an Seiten angelegt hast, muß immer mit Statuscode 404 ausgeliefert werden. Andernfalls wird sie sozusagen "durch die Hintertür" doch noch zum Leben erweckt.

Natürlich kannst du den Statuscode auch per header() ausgeben, und dann deine Startseite dranklatschen. Ich würde es aber besser finden, nicht die Startseite, sondern eine Fehlermeldung zu sehen. Dass deine Navigationselemente auf dieser Seite enthalten sein können, ist ja nicht verboten. Dann kommt der Besucher zumindest schon mal thematisch weiter - entweder zur Startseite, oder direkt dorthin, wohin er eigentlich wollte.

Ein paar Kritiken hatte ich ja noch,
es geht ja nicht nur um ein einziges Projekt, sondern um
eine logische und einfache Grundstruktur für alle
kommenden kleinen oder riesengroßen Projekte.

Ich empfehle, die Dinge nicht zu groß und unübersichtlich werden zu lassen. Die Trennung zwischen zwei voneinander als unabhängig zu betrachtenden Projekten ist im Zweifel immer die Domaingrenze (auch Subdomains bilden diese Grenzen). Für jedes Projekt allein muß die URL-Umschreibung stimmig sein und passen. Sie darf natürlich überall gleichartig sein - dann setzt es sich leichter Links.

Wie sieht es eigentlich in Deinen Statistiken aus,
werden dann die eingetippten URL's aufgelistet,
oder Dein Script?

Da werden praktischerweise die eingetippten URLs aufgelistet.

Und der Vorteil solch einer Sache ist ja: Du bist von der Art der Seitenerzeugung her vollkommen frei in der Wahl deiner Mittel. Wenn du irgendwann feststellst, dass du performancemäßig mit PHP-generierten Seiten nicht mehr hinkommst, kannst du (sofern das vom Inhalt her geht) die Seiten ja auch als statische Kopie generieren lassen und auf dem Server ablegen.

Oder du setzt ein anderes Skript ein. Das kann einen Teilbereich der URLs komplett anders behandeln und ausliefern. Also beispielsweise ein Forumsskript, welches groß ist, viel Power zum Skriptstart benötigt, aber nicht sehr häufig aufgerufen wird - warum soll man das auch für die simple Seitengenerierung beim statischen Content einsetzen, da reicht doch ein schnelles, kleines Skript.

Gegenüber der Außenwelt (Bookmarks, externe Links, Suchmaschinen) sieht dein Server immer gleich aus.

- Sven Rautenberg