tinyweb.de

... hat Tim Berners-Lee in Cool URIs don't change diskutiert. Schließlich kann man nicht wissen, wer die alte, nun ungültige URL noch als Link oder Bookmark irgendwo gespeichert hat. Und man will doch bestimmt nicht, dass ein Besucher ins Leere läuft, nur weil sich die URL geändert hat. Woher sollte der Besucher, der sich vielleicht vor Monaten einen Bookmark auf die Seite gesetzt hat, dies auch wissen?

Wenn die Seite wirklich wichtig für ihn war, wird der Besucher vielleicht noch kurz danach suchen (indem er die letzten ein oder zwei Verzeichnisebenen aus der URL löscht). Aber spätestens dann wird er schulterzuckend (und vermutlich fluchend) weiter ziehen und man hat einen Besucher für immer verloren.

Das muss doch nicht sein

Durch vernünftige Organisation und Planung einer Website lässt sich das Problem bereits von vornherein vermeiden. In Cool URIs don't change findet man dazu auch viele nützliche Tipps, wie man URLs so aufbaut, dass sie möglichst lange "halten", d.h. nicht geändert werden müssen.

Und wenn es dann doch einmal passiert?

Wenn sich eine URL - aus welchen Gründen auch immer - dann doch einmal ändert, sollte man den Besucher nicht im Regen stehen lassen und mit einem lapidaren "404 Seite nicht gefunden" konfrontieren. Eine Möglichkeit wäre, dem Besucher eine Ersatz-Seite zu präsentieren, die ihn über die Änderung informiert und nach Möglichkeit gleich dorthin weiterleitet.

Besser ist es aber, dies dem Webserver zu überlassen. Der am weitesten verbreitete Webserver, Apache von der Apache Group, ermöglicht dies durch die Direktive Redirect. Andere Webserver verfügen über ähnliche Möglichkeiten.

Indem man die Weiterleitung vom Webserver vornehmen lässt, geschieht die Umlenkung nicht nur automatisch, sondern der Webserver kann auch einen Statuscode mitschicken, der den Browser des Besuchers über die geänderte URL informiert. Manche Browser passen dann ihre Bookmarks automatisch an die geänderte Adresse an. Besonders nützlich ist dies aber für Suchmaschinen, die ebenfalls den Statuscode auswerten und dann automatisch die geänderte Seite aufnehmen und die alte URL "vergessen". Hätte man stattdessen eine HTML-Seite dazwischengeschaltet, die über die Änderung informiert, hätte die Suchmaschine diese Seite in ihren Index aufgenommen - was im Normalfall aber sicher nicht erwünscht ist.

Die Redirect-Direktive

(Dies ist eine Übersetzung des Abschnitts über die Redirect-Direktive aus dem Apache-Manual)

Syntax: Redirect [status] URL-pfad URL
Context: server config, virtual host, directory, .htaccess
Override: FileInfo
Status: Base
Module: mod_alias
Compatibility: Der Context für directory und .htaccess ist nur in Versionen 1.1 und neuer verfügbar. Das Argument status ist nur in Apache 1.2 oder neuer verfügbar

Die Redirect-Direktive bildet eine alte URL auf eine neue ab. Die neue URL wird an den Klienten zurückgeliefert, der darauf hin versuchen wird, das Dokument unter der neuen Adresse abzurufen. URL-pfad ist ein (%-dekodierter) Pfad. Alle Anfragen für Dokumente, die mit diesem Pfad beginnen, werden mit einer Umleitungsmeldung auf eine neue (%-kodierte) URL, die mit URL beginnt, beantwortet.

Beispiel:

Redirect /service http://foo2.bar.com/service

Wenn der Klient http://myserver/service/foo.txt anfordert, wird er angewiesen, stattdessen http://foo2.bar.com/service/foo.txt abzurufen.

Hinweis: Redirect-Direktiven haben Vorrang gegenüber Alias- und ScriptAlias-Direktiven, unabhängig von ihrer Position im Konfigurations-File. Außerdem muss URL-pfad ein absoluter Pfad, kein relativer Pfad, sein, auch wenn er in einer .htaccess-Datei oder in einem <Directory>-Abschnitt benutzt wird.

Wenn kein status-Argument angegeben wird, wird die Umleitung "temporär" sein (HTTP-Status 302). Dies teilt dem Klienten mit, dass die Resource nur vorübergehend unter der neuen Adresse abgelegt ist. Das status-Argument kann dazu benutzt werden, folgende HTTP-Status zurückzugeben:

permanent: Gibt den Status "permanente Umleitung" (301) zurück, um anzuzeigen, dass die Resource permanent unter der neuen Adresse abzurufen ist.
temp: Gibt den Status "vorübergehende Umleitung" (302) zurück. Das ist auch der Default-Wert fü status.
seeother: Gibt den Status "siehe auch" (303) zurück, um anzuzeigen, dass die Resource ersetzt wurde.
gone: Gibt den Status "existiert nicht mehr" zurück, um anzuzeigen, dass diese Resource entfernt wurde und auch nicht mehr unter einer anderen Adresse existiert. Bei diesem Wert für status sollte für URL kein Wert eingesetzt werden.

Darüber hinaus können beliebige andere Statuscodes zurückgegeben werden, indem man ihren numerischen Wert für status einsetzt. Wenn der Statuscode im Bereich 300 bis 399 liegt, muss ein Wert für URL angegeben werden, andernfalls kann er weggelassen werden. Außerdem muss der Status ein dem Apache bekannter Code sein (siehe die Funktion send_error_response in http_protocol.c).

Neben den Direktiven RedirectPermanent und RedirectTemp, die nur andere Schreibweisen für die Redirect-Direktive mit dem Status permanent bzw. temp sind, gibt es auch noch die Direktive RedirectMatch, bei der man einen regulären Ausdruck als alte URL angeben kann.

Anwendung

Und wohin schreibt man nun die Redirect-Direktive? Wenn man nicht gerade Zugriff auf den Apache selbst und seine Konfigurationsdatei httpd.conf hat, so legt man eine Datei namens .htaccess (der Punkt gehört zum Namen) an. Diese Datei kopiert man am Besten in die höchste Verzeichnisebene, auf die man Zugriff hat. Bei einer eigenen Domain also in das Wurzelverzeichnis.

Wie in der Beschreibung erwähnt, muss der erste Pfad ein absoluter Pfad sein, d.h. er muss den gesamten Pfad von der obersten Ebene bis zu der nun nicht mehr existierenden Datei beschreiben. Der zweite Pfad muss dann die komplette URL (inkl. http://) der neuen Datei beschreiben. Dazu ein paar Beispiele aus der Praxis:

Diese beiden Redirect-Direktiven stammen aus der .htaccess meiner privaten Homepage http://www.haun-online.de/. Die erste Direktive gibt an, dass das Dokument pb100.html, das ehemals im Verzeichnis /Macintosh/HTML lag, nun unter der neuen Adresse http://68kMac.de/Museum/pb100.html zu finden ist. Nachdem sich im Laufe der Zeit einige Dokumente angesammelt hatten, die sich mit 68k-Macs beschäftigen, beschloss ich irgendwann, dafür eine eigene Site einzurichten. Und natürlich sollen Besucher, die noch die alte URL gespeichert haben, auf die neue Site umgeleitet werden (natürlich direkt zu dem Dokument, das sie suchen und nicht einfach zur Startseite, von wo sie sich dann erst wieder zu dem gesuchten Dokument durchklicken müssten).

Das zweite Beispiel bügelt einen Designfehler aus. Die Entscheidung, gemischte Groß-/Kleinschreibung in den URLs zu verwenden, war, im Nachhinein betrachtet, keine sehr geschickte. Viele Leute erwarten bei URLs offenbar doch Kleinschreibung bzw. sind sich nicht bewusst, dass die Groß-/Kleinschreibung doch eine Rolle spielt. Besonders offensichtlich wurde dies, nachdem die genannte URL in einem Zeitungsartikel abgedruckt wurde und sich in den nächsten Tagen die 404-Fehlermeldungen im Logfile häuften, weil versucht wurde, auf die Adresse per Kleinschreibung zuzugreifen. Die Redirect-Direktive lenkt übrigens alle Zugriffe um, die mit dem klein geschriebenen /macig beginnen, auch wenn z.B. direkt auf die Datei /macig/termine.html zugegriffen werden soll.

Tipps

Wenn man sich nicht sicher ist, auf welchem Webserver die eigenen Webseiten liegen, kann man versuchen, einfach eine nicht existierende URL aufzurufen (absichtlich einen Tippfehler in einen Dateinamen einbauen oder einen nicht existierenden Dateinamen verwenden). Je nachdem, wie der Webserver eingerichtet ist, wird er dann entweder eine speziell vom Provider eingerichtete Fehlerseite oder die Default-Fehlerseite des Webservers anzeigen. Für den Apache wird letztere dann in etwa so aussehen:

Hier läuft also offensichtlich ein Apache-Webserver in der Version 1.3.20. Lässt sich der Webserver auf diese Art nicht ermitteln, muss man eben beim Provider nachfragen.

Im Gegensatz zu HTML-Dokumenten ist es bei der Datei .htaccess wichtig, dass man den korrekten Zeilentrenner verwendet. Da der Apache zumeist unter einem Unix-System läuft, ist der korrekte Zeilentrenner das Zeichen LF (Linefeed, ASCII 10). Wenn man die Datei daher unter Windows oder auf einem Mac erstellt, sollte man entweder einen Editor verwenden, der die Wahl des Zeilentrenners erlaubt oder man überträgt die Datei im FTP-Programm im ASCII-Modus, wodurch die Zeilentrenner beim Hochladen der Datei automatisch richtig konvertiert werden. Wenn man die Datei mit falschen Zeilentrennern auf den Webserver überträgt, kann das u.U. die ganze Website außer Funktion setzen (beim Apache erhält man dann typischerweise einen "Internal Server Error" mit Fehlercode 500).

Warum sich die URL einer Seite nicht ändern sollte ...

Das muss doch nicht sein

Und wenn es dann doch einmal passiert?

Die Redirect-Direktive

Anwendung

Tipps

Links