Ich   Entwicklung   Lösungen Apache PHP mySQL  
 

Fehlerseiten mit Apache und PHP

Dieser Artikel erläutert, wie Sie mit der Apache-Direktive ErrorDocument eigene Fehlerseiten bestimmen können. Es wird erklärt, warum Sie eigene Fehlerseiten anlegen und wie diese aussehen sollten. Schließlich wird noch gezeigt, wie Sie mit PHP Fehlerseiten dynamisch erstellen können.

Warum eigene Fehlerseiten?

Zu einer ergonomischen Webseite gehört es auch, Fehler nicht stiefmütterlich zu behandeln, sondern den Benutzer zu unterstützen, falls ein Fehler auftritt. Für Fehlerseiten ist es also wichtig,

  • dass sie sich nahtlos in Ihre Website einpassen, damit der Nutzer nicht das Gefühl hat, Ihre Webseite verlassen zu haben und auf einen schwerwiegenden Fehler gestossen zu sein,
  • dass sie den Nutzer dabei unterstützen, die Ursache des Fehlers zu erkennen und ihm Hilfe anbieten, wie weiter verfahren werden kann,
  • dass die Fehlermeldung auffällig und klar, aber nicht abschreckend ist.

Jakob Nielsen schrieb dazu schon 2001 einen Artikel (Error Message Guidelines), indem er die folgenden Anforderungen an die Fehlerbehandlung stellt:

  • Bei einem Fehler muss es eine Fehlermeldung geben!
  • Die Fehlermeldung muss verständlich, höflich und präzise sein.
  • Bem Benutzer soll ein konstruktiver Vorschlag zur Fehlerbehandlung gemacht werden.

Wie funktioniert es technisch?

Dieser Artikel behandelt die Möglichkeiten des weit verbreiteten Apache Webservers. Für andere Webserver gibt es ähnliche Lösungen, auf die ich nicht weiter eingehen kann.

Das Protokoll HTTP sieht vor, dass ein Webserver u.a. mit einen Statuscode auf eine Anfrage eines Clients antwortet. Allgemein bekannt ist der Statuscode 404, der angibt, dass der Webserver die angefragte Ressource nicht finden konnte. Nun schickt der Webserver standardmäßig auch einen HTTP-Body (also eine Webseite) an den Client, der den Besucher kurz, aber entgegen allen oben beschriebenen Anforderungen, über den Fehler informiert (Abbildung 1).

Eine Erklärung aller HTTP-Statuscodes finden Sie in der RFC 2616 (HTTP/1.1 von 1999) in Abschnitt 10. Einige oft auftretende Fehler werden weiter unten besprochen.


Abbildung 1: Fehlerseite des Apache im Firefox

Meiner Meinung nach noch schlechter ist die Fehlerseite des Microsoft Internet Explorer, die angezeigt wird, wenn entweder kein oder nur ein kurzer HTTP-Body vom Webserver verschickt wird (Abbildung 2). Sie versucht zwar, Hilfestellungen zu geben und zeigt die Fehlermeldung in der Sprache des Betriebssystems an, doch hat man mit Ansicht dieser Fehlerseite den Webserver praktisch komplett verlassen. Negativ ist aber vor allem das Gebaren, dem Benutzer nicht die vom Webserver zugeschickte Fehlerseite anzuzeigen, sondern eine vom Browserhersteller geschriebene.


Abbildung 2: Fehlerseite des Internet Explorers

Die Direktive ErrorDocument

In der Konfigurationsdatei des Apache können eigene Fehlerseiten angegeben werden, die den Benutzer besser unterstützen. Webautoren, die keinen Zugriff auf die Konfigurationsdatei haben (was bei den meisten Providern der Fall ist), können dazu die sog. Zugriffskontrolldateien des Apache nutzen, die den Dateinamen .htaccess besitzen müssen und für das Verzeichnis und alle seine Unterverzeichnisse gelten, in denen sie gespeichert ist.

In der Dokumentation des Apache wird ein Beispiel ähnlich dem folgenden für die Nutzung der Direktive aufgeführt:

ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 default
ErrorDocument 401 /info_zur_anmeldung.html
ErrorDocument 403 "Der Zugriff ist nicht erlaubt."

Die erste Zeile ruft einen absoluten URL auf, wenn der Statuscode 500 gesendet wird, der zweite schickt bei einem 404 die Standard-Fehlerseite des Apache. Bei einem 401 wird ein URL der gerade aufgerufenen Domain geschickt, die letzte Zeile schickt einfach nur eine Zeichenkette.

Dabei kann ich von allen außer der dritten Methode nur abraten, da sie entweder keine Verbesserung oder weitere Probleme mit sich bringen. Sehr praktikabel und hilfreich ist jedoch der Aufruf eines URL auf der gerade aufgerufenen Domain, wie hier beim Statuscode 401 geschehen.

Wenn Sie einfache HTML-Fehlerseiten nutzen möchten, weil Sie kein PHP (oder eine andere Skriptsprache) benutzen können oder möchten, dann sollten in Ihrer .htaccess-Datei etwa folgende Einträge vorhanden sein:

ErrorDocument 401 /fehlerseiten/401.html
ErrorDocument 403 /fehlerseiten/403.html
ErrorDocument 404 /fehlerseiten/404.html
ErrorDocument 500 /fehlerseiten/500.html

Dies bewirkt, dass bei einem Aufruf von http://www.example.com/dieser/url/ist/nicht/vorhanden/gibts.nicht der Apache dem Client die Seite http://www.example.com/fehlerseiten/404.html schickt. Entgegen vielen anderen Apache-Direktiven ist hier also kein absoluter Server-Pfad anzugeben, sondern ein Pfad ausgehend von der Wurzel der aufgerufenen Domain!

HTTP-Statuscodes zur Anzeige von Fehlern

Die Statuscodes sind folgendermaßen unterteilt:

  • 1xx informativ (z.B. Protokollwechsel)
  • 2xx erfolgreich (der gängiste Code überhaupt: 200 OK)
  • 3xx Weiterleitungen (siehe auch mein Artikel zu Weiterleitungen)
  • 4xx Client-Fehler
  • 5xx Server-Fehler

400 - Bad Request

Die Syntax des Aufrufs war falsch. Kommt selten vor, aber eine Behandlung schadet nicht.

401 - Unauthorized

Mit diesem Statuscode fordert der Server eine Authentifizierung an (Eingabe eines Benutzernamens und eines Passworts). Wird eine Fehlerseite für diesen Statuscode angegeben, so wird diese bei jedem Authentifizierungs-Versuch verarbeitet, aber der Content nur bei einem Abbruch vom Browser angezeigt! Mit anderen Worten: wenn Sie einen Passwort-geschützten Bereich erstellen und Ihre Fehlerseite nicht nur HTML ausgibt, sondern beispielsweise auch eine Fehlermeldung an den Administrator sendet (z.B. per E-Mail), so wird diese Meldung nicht erst verschickt, wenn der Anmeldeversuch fehlschlägt, sondern schon bei der Anforderung zur Authentifizierung durch den Server!

403 - Forbidden

Der Server verbietet den Zugriff auf die angeforderte Ressource. Üblicherweise heißt das: ein Verzeichnis wurde aufgerufen, dass keine index-Datei enthält und der Server ist so konfiguriert, keine Verzeichnis-Listings anzuzeigen. Beispiel: http://www.intermitto.net/skripte/.

404 - Not Found

Der Server hat keine Ressource gefunden, die mit dem angeforderten URI übereinstimmt. Meist hat ein Webautor die Struktur seiner Website umgestellt, oder ein Link ist falsch geschrieben. Natürlich kann ein Nutzer auch mutwillig den URL manipulieren, um dieses Ergebnis zu erzielen. Falls Sie als Webautor wirklich Dateien umbenennen müssen, ziehen Sie in Betracht, von den alten URLs zu den neuen URLs weiterzuleiten (per Statuscodes 3xx, siehe auch mein Artikel zu Weiterleitungen). Falls die angeforderte Ressource wirklich nicht mehr verfügbar ist, weil sie absichtlich entfernt wurde und es auch keinerlei Ersatz gibt, dann sollten Sie dies dem Apache mitteilen (er wird dann den Statuscode 410 senden, was für den Besucher informativer ist; mehr Informationen dazu beispielsweise auf http://diveintomark.org/archives/2003/03/27/http_error_410_gone).

410 - Gone

Der Statuscode 410 besagt, dass die Ressource permanent und absichtlich entfernt wurde, dies sollten Sie Ihren Besuchern auch mitteilen.

500 - Internal Server Error

In HTTP kaum näher erläutert tritt der Statuscode 500 meist dann auf, wenn ein Skript oder eine Zugrisskontrolldatei einen Fehler verursacht haben. So verursacht eine syntaktisch falsche Zugriffskontrolldatei oder eine, in der Einstellungen vorgenommen werden, die dort per Apache-Konfiguration verboten sind, einen Statuscode 500. Gerade hier ist es wichtig, dem Benutzer Hilfestellung zu geben, obwohl es ausgerechnet bei einem Statuscode 500 besonders schwierig sein kann.

Einfache Möglichkeiten der Hilfestellung

Wenn Sie kein PHP einsetzen können oder möchten, sollten Sie immerhin versuchen, die oben genannten Punkte zur Lösung der Fehler zu beachten. Helfen Sie Ihrem Besucher!

  • Geben Sie Ihrem Besucher Kontaktmöglichkeiten (E-Mail-Adresse, Kontaktformular).
  • Bei nicht gefundenen Seiten bieten Sie eine Sitemap an.
  • Überlegen Sie sich für jeden Fehler Lösungen.

Dynamische Fehlerseiten mit PHP

Falls Ihre Webseite, wie intermitto.net, dynamisch per PHP erstellt wird, bietet sich dies natürlich auch für die Fehlerseiten an. Auf diese Weise können Sie die Fehlermeldung im Rahmen Ihrer normalen Webseite anzeigen. Außerdem haben Sie per PHP natürlich die Möglichkeit, den Administrator über Fehler zu benachrichtigen und verbesserte Hilfestellung zu leisten.

Ein Beispiel für eine .htaccess-Datei, die den aufgetretenen Fehler an Ihr PHP-Skript übergibt, welches die Webseite erzeugt:

ErrorDocument 401 /index.php?errorcode=401
ErrorDocument 403 /index.php?errorcode=403
ErrorDocument 404 /index.php?errorcode=404
ErrorDocument 410 /index.php?errorcode=410
ErrorDocument 500 /index.php?errorcode=500

Umgebungsvariablen

Schließlich möchte ich noch einige Umgebungsvariablen vorstellen, die Ihnen der Apache bzw. PHP zur Verfügung stellen. Mit Hilfe dieser Variablen können Sie besser Lösungsmöglichkeiten anbieten, oder zumindest eine genauere Fehlerbeschreibung an den Administrator senden.

$_SERVER["HTTP_HOST"] Der Domainname, z.B. www.intermitto.net
$_SERVER["HTTP_USER_AGENT"] Die Client-Software. Meist Browser, oft aber auch Suchmaschinen oder Browser-Plugins
$_SERVER["REMOTE_ADDR"] Die IP des Clients
$_SERVER["REMOTE_USER"] Gerade für den Statuscode 401 interessant. Ist der vom Client an den Server gesendete Benutzername nach Authentifizierung.
$_SERVER["REQUEST_METHOD"] Die HTTP-Anfragemethode, meist GET oder POST.

Beachten Sie, dass übliche Umgebungsvariablen wie QUERY_STRING während der Ausführung der Fehlerseite nicht mehr dieselben sind wie beim nicht geglückten Aufruf! Der Apache bietet seit Version 2 allerdings Abhilfe durch die folgenden Variablen:

$_SERVER["REDIRECT_HTTP_USER_AGENT"] Wie oben, aber eben zum Zeitpunkt, als der Fehler auftrat.
$_SERVER["REDIRECT_QUERY_STRING"] Der ursprüngliche Query String (also per GET übergebene Parameter).
$_SERVER["REDIRECT_URL"] Der ursprünglich aufgerufene URL.
$_SERVER["REDIRECT_STATUS"] Der ursprüngliche Statuscode, entspricht dem Fehlercode.

Diesen Variablen stehen nur dann zur Verfügung, wenn in der ErrorDocument-Direktive wie empfohlen lokale Fehlerseiten angegeben werden. Bedenken Sie also, dass die Angabe eines externen URL als Fehlerseite auch zur Folge hat, dass Ihnen weniger Umgebungsvariablen zur Verfügung stehen, mit denen Sie den Fehler identifizieren können!

Wie geht es noch besser?

Dieser Artikel kann Ihnen natürlich nur eine Einführung bieten. Selbst ich habe nicht alle Möglichkeiten genutzt, dem Besucher von intermitto.net im Fehlerfall zu helfen, da mir einfach die Zeit dazu fehlt und einige weiterreichende Hilfen teils aufwändig umzusetzen sind.

Ein gutes Beispiel ist bei einem Statuscode 404 die Möglichkeit, den URL (samt Query String)

  • nach Begriffen zu durchsuchen, die einen Hinweis darauf geben, was der Benutzer sucht (wenn die komplette Webseite aus einer Datenbank kommt, könnte diese durchsucht werden, oder zu jeder Seite gibt es Stichwörter, die durchsucht werden),
  • auf Schreibfehler zu überprüfen, was natürlich softwaretechnisch aufwändig ist.

Ein Artikel von Michael Jendryschik geht mehr auf die Gestaltung der Fehlerseiten und einige Richtlinien ein.

URL: www.intermitto.net/loesungen/artikel/fehlerseiten/
© 2004-05 Jens Becker - intermitto.net v5.1
Letzte Änderung: 23.08.2005

Home - Kontaktformular - Downloads - Suche und Sitemap - Impressum
Entwicklung - Problemlösungen - Tutorials: Apache PHP mySQL

user  pass