brauchbar.de - WebDesign, Programmierung,Development in HTML, CSS, Javascript, PHP, Perl und mehr

[ Startseite | Artikel : HTML · JavaScript · CSS · Perl · Usability · Sonstiges | Services | Über ]


verwandte Artikel und Seiten

Eigene Fehlermeldungen und was man mit ihnen anfangen kann III -- PHP

von Eric Horn.

In diesem Teil:

1. Das Problem

Bereits im "Eigene Fehlermeldungen und was man mit ihnen anfangen kann I" hat Friedemann Lindenthal gezeigt, wie man sich von den standardisierten Fehler-Seiten trennen und damit der eigenen Homepage ein professionelles Auftreten verpassen kann. Im vorliegenden Artikel soll es nun darum gehen, wie man insbesondere mit den 404er-Fehlern ("Page Not Found") umgehen kann. Denn das von Friedemann vorgestellt Verfahren, Fehler durch Manipulation der Datei .htaccess auf eigene Seiten umzuleiten, bringt einen gravierenden Nachteil mit sich: Alle Fehler, die auf diese Weise durch Umleitung behandelt werden, werden auf dem Server nicht mehr als Fehler erkannt. Konkret auf den 404er-Fehler bezogen heißt das:

  1. Ein Link-Checker wie HTDIG oder Xenu findet keine fehlenden Seiten mehr, da ihm vom Server nicht der Status 404 übermittelt wird, sondern statt dessen eine ganz normale Seite, nämlich das 404er-Dokument.

  2. In den LOG-Dateien für den Server-Zugriff wird ebenfalls für fehlende Seiten kein 404er-Status eingetragen, sondern statt dessen der Status 302 ("Page Temporarily Moved"). Da die wenigsten LOG-Analyseprogramme jedoch eine Überprüfung des 302er-Status vornehmen, hat man keinen Zugriff auf diese Meldungen.

Das bedeutet also konkret: die Einrichtung einer Fehler-Umleitung für den 404er-Fehler per Datei .htaccess nimmt dem Webmaster erst einmal jede Möglichkeit, fehlende Links auf dem eigenen Server zu erkennen - es sei denn, er geht manuell die kompletten LOG-Dateien durch und sucht nach allen Aufrufen des Umleitungsdokumentes.

2. Die Lösung

Die Lösung dieses Problems ist denkbar einfach: Man lässt 404er-Fehler nicht auf statische Internetseiten weiterleiten, sondern auf dynamische, die mit Hilfe eines Scripts den Fehler analysieren und entsprechende Maßnahmen einleiten. Im "Eigene Fehlermeldungen und was man mit ihnen anfangen kann II" dieser Artikelserie erklärte Thomas, wie man dies mit Hilfe eines CGI-Scripts erreicht. An dieser Stelle soll eine Variante besprochen werden, die mit PHP realisiert wird. Warum verwende ich für dieses Vorhaben PHP? Zum einen muss ich gestehen, dass PHP bei mir meist Vorzug vor CGI-Scripten bekommt, da einige Stärken (etwa die direkte Integration in das HTML-Dokument, einfachere Programmstrukturen etc.) einfach für sich sprechen. Andererseits ist PHP vom Sicherheitsaspekt her für Administratoren wesentlich einfacher zu installieren und konfigurieren, da man mit wenigen Einstellungen die Möglichkeiten, die man dem Anwender gibt, festlegen kann. Auf diese Weise bieten immer mehr Hoster PHP-Unterstützung an, obwohl sie keine eigenen CGI-Scripte zulassen. Als Server-Administrator bevorzuge ich PHP auch deshalb, da die Evaluierung eines PHP-Programms weniger Server-Leistung kostet als das Ausführen eines CGI-Scripts; alles Gründe, weshalb in nächster Zeit PHP wohl früher oder später Perl den Rang ablaufen wird.

Was soll nun das Script können? Das im Folgenden hier vorgestellte Script ermittelt die Daten, die zum 404er-Fehler führten (fehlendes Dokument und aufrufendes Dokument). Handelt es sich um einen internen Fehler - wird also innerhalb der eigenen Seiten auf eine fehlende Datei gelinkt - wird eine entsprechende interne Fehlermeldung ausgegeben, handelt es sich um einen externen Fehler - linkt also z.B. eine fremde Seite auf ein Dokument des eigenen Servers, das nicht oder nicht mehr existiert - wird eine entsprechende externe Fehlermeldung ausgegeben. Nicht berücksichtigt werden Fehler, die aufgrund veralteter Bookmarks oder fehlerhafter URL-Direkt-Eingaben eines Benutzers entstehen - man kann sich ja schließlich nicht um alles kümmern. Anhand interner Fehlermeldungen kann man eigene Links korrigieren, anhand der externen Fehlermeldung kann man die fremde Seite aufrufen, um sich dann bei Bedarf die Adresse des Webmasters heraus zu suchen und ihm eine Mail mit Bitte um Abänderung des Links zukommen zu lassen. Alle Fehlermeldungen können entweder in einer eigenen LOG-Datei dokumentiert werden oder aber (so mache ich es) live an die Mail-Adresse des Webmasters versendet werden. Als besonderes Feature bietet das Script zusätzlich die Möglichkeit, eine Mapping-Datei anzulegen, in der man Dateiverschiebungen oder -umbenennungen dokumentiert. Heißt zum Beispiel die Impressum-Seite nicht mehr impressum.html, sondern info.html, dann kann man dies in der Mapping-Datei hinterlegen. Wird nun ein 404er-Fehler durch Aufruf einer auf diese Weise "gemappten" Datei erzeugt, leitet das Script automatisch auf die neue Seite weiter, ohne dass der Benutzer davon direkt was mitbekommt.

Teil 2 weiter

Eric Horn
http://www.horn-netz.de

Möchten auch Sie einen kürzeren oder längeren Artikel im WebDesign-Newsletter veröffentlichen?
Gerne höre und sehe ich mir Ihre Vorschläge an. Senden Sie sie doch bitte an salvador@brauchbar.de.


Verwandte Artikel und Seiten



brauchbar web
Diese Site anlinken. Artikel zu CSS | HTML | JavaScript | Perl | Usability | Sonst. | nach Ausgabe.

Copyright © 1999-2015 Thomas Salvador und brauchbar.de . Alle Rechte vorbehalten. Gehostet bei all-inkl.
Reproduktion, ganz oder in Teilen, nur mit schriftlicher Zustimmung von Thomas Salvador. Impressum · Datenschutzerklärung · Kontakt.

zum Inhaltsverzeichnis der 27. Ausgabe.

Linken Sie bitte zu der festen Adresse http://www.brauchbar.de/wd/artikel/91.html .