Die HTTP/1.1-Spezifikation definiert eine ganze Reihe von Fehlercodes, darunter die Fehler 401 (Unauthorized), 403 (Forbidden) 404 (Not Found) und 410 (Gone). Die im Falle eines Fehlers angezeigten Standardfehlerseiten reichen nicht aus, um Nutzer mit den notwendigen Informationen zur Fehlerbehandlung und weiteren Vorgehensweise zu versorgen. Dieser Artikel zeigt, wie Sie Ihre Besucher auf selbst gestaltete Fehlerseiten leiten und welche Informationen diese enthalten sollten.
Einleitung
Die erste Zeile (Statuszeile) des HTTP-Response eines Webservers entspricht stets folgendem Schema:
HTTP/<Version> <Statuscode> <Statustext>
Bei einer korrekt ausgelieferten Ressource sieht die Statuszeile in den meisten Fällen wie folgt aus:
HTTP/1.1 200 OK
Die HTTP/1.1-Spezifikation definiert in Abschnitt 10 alle in Frage kommenden Statuscodes, darunter auch eine Handvoll Fehlercodes. Ich stelle im Verlauf dieses Artikels vor allem die in der folgenden Tabelle aufgeführten Fehlercodes näher vor und zeige, wie Sie Ihre Besucher auf selbst gestaltete Fehlerseiten leiten und welche Informationen diese enthalten sollen.
| Fehlercode | Statustext | Beschreibung |
|---|---|---|
| 401 | Unauthorized | Der Benutzer benötigt eine Autorisierung, ohne die er keinen Zugriff auf die Ressource hat. |
| 403 | Forbidden | Nicht öffentlicher Bereich, auf den der Benutzer keinen Zugriff hat. |
| 404 | Not Found | Die Ressource wurde unter dem angegebenen URI nicht gefunden. |
| 410 | Gone | Unter dem angegebenen URI ist keine Ressource mehr erreichbar und es ist keine Weiterleitungsadresse bekannt. |
Standardfehlerseiten vermeiden
Jeder, der hin und wieder mal im Web surft, kennt (leider) die Standardfehlerseiten, die Browser anzeigen, wenn vergeblich versucht wird, eine vermeintlich vorhandene Ressource aufzurufen oder in einen passwortgeschützten Bereich zu gelangen. Derartige Standardfehlerseiten sollten Sie Ihren Besuchern nicht zumuten, denn diese reichen nicht aus, sie mit den notwendigen Informationen zur Fehlerbehandlung zu versorgen. Gerade unerfahrene Besucher blicken in vielen Fällen ratlos auf die Fehlerseite und wissen nicht, was sie nun tun können, um an die gesuchte Information zu gelangen. Darüber hinaus wirkt das minimalistische Design abschreckend und gibt Besuchern das Gefühl, Ihre Website verlassen zu haben. Viel besser ist es, eigene Fehlerseiten zu gestalten und diese an das Design der Website anzupassen; sie sollten über Kernelemente wie Site Label und Navigation verfügen sowie dem grundsätzlichen Aufbau der Website entsprechen.
Jeder Webserver bietet die Möglichkeit, eigene Fehlerseiten anzulegen. Beim Apache Webserver können Sie diese über die Direktive ErrorDocument sowohl global in der Konfigurationsdatei httpd.conf festlegen, sofern Sie auf diese zugreifen können, als auch in Zugriffskontrolldateien (htaccess-Dateien). Letztere wirken sich nur auf das Verzeichnis aus, in dem sie angelegt werden, sowie auf dessen Unterverzeichnisse.
Die Direktive ErrorDocument
Die ErrorDocument-Direktive hat folgende Syntax:
ErrorDocument <Fehlercode> <Aktion>
Als Aktion können Sie einen externen oder lokalen URI zur einer eigenen Fehlerseite sowie Text angeben, der anstatt der Standardfehlermeldungen angezeigt wird. Dieser Text kann auch Markup beinhalten. Bitte beachten Sie, dass dieser Text im Apache 1.4 durch ein Anführungszeichen (U+0022) eingeleitet und im Apache 2.0 durch Anführungszeichen umfasst wird.
ErrorDocument 401 http://www.example.com/error/401 ErrorDocument 403 /error/403.php ErrorDocument 404 "<h1>Fehler 404</h1><p>Das Dokument konnte nicht gefunden werden.</p>"
Wenn Sie auf eine externe Ressource verweisen, sollten Sie beachten, dass der Apache Webserver eine Weiterleitung zum Client sendet, um diesem mitzuteilen, wo das Dokument zu finden ist, auch wenn das Dokument letztlich wieder zum gleichen Server führt. Das führt unter anderem dazu, dass der Client zumindest vom Apache 1.3 nicht den Original-Statuscode erhält, sondern stattdessen einen Weiterleitungs-Statuscode. Dies wiederum kann Suchroboter und andere Clients verwirren, die den Statuscode dazu verwenden, herauszufinden ob ein URI gültig ist. Wenn Sie eine Fehlerseite für den Fehlercode 401 anlegen, wird der Client darüber hinaus nicht wissen, dass er den Benutzer zur Eingabe eines Passworts auffordern muss, da er den Statuscode 401 nicht erhält. Sie müssen deshalb stets auf eine interne Ressource verweisen, wenn Sie eine Fehlerseite für 401-Fehler anlegen wollen.
An dieser Stelle zeigt sich mal wieder ein Fehler im Internet Explorer in den Versionen 5.x und 6.x. Wenn Sie auf eine Fehlerseite verweisen, die kleiner als 512 Bytes groß ist, wird die Standardfehlerseite angezeigt. Achten Sie also darauf, dass Ihre Fehlerseiten ausreichend groß sind, sodass sie auch diesen Browsern »auffallen«.
Richtlinien für Fehlermeldungen
Hilfreiche Fehlermeldungen sind auffällig, verständlich und höflich formuliert, beschreiben das Problem präzise und geben konstruktive Hinweise, wie der Fehler zu beheben ist.
- Fehlermeldung auffällig gestalten
- Die Aufgabe von Fehlermeldungen ist es, den Nutzer darauf aufmerksam zu machen, dass etwas schief gelaufen ist. Gestalten Sie Ihre Fehlerseiten so, dass sich die eigentliche Fehlermeldung deutlich und auffällig präsentiert und klar ausdrückt, dass ein Fehler aufgetreten ist.
- Fehlermeldungen verständlich formulieren
- Fehlermeldungen sollten auch dann verständlich sein, wenn die technischen Zusammenhänge nicht bekannt sind. Die meisten Benutzer können mit einer allein stehenden Meldung »Fehler 404« nichts anfangen. Besser ergänzen Sie sie durch eine verständliche Ergänzung wie beispielsweise »Seite nicht gefunden«.
- Fehlermeldungen höflich formulieren
- Wählen Sie bei Ihren Fehlermeldungen eine Formulierung, die den Besuchern nicht das Gefühl gibt, sie hätten einen dummen, vermeidbaren Fehler begangen. »Seite nicht gefunden« beschreibt den vergeblichen Aufruf einer Ressource neutraler als »Fehlerhafte Eingabe« oder eine ähnlich offensive Formulierung.
- Fehler präzise beschreiben
- Treffen Sie eine klare Aussage darüber, welcher Fehler aufgetreten ist. Es kann einen Unterschied machen, ob eine Ressource unter einem URI noch nie erreichbar war oder lediglich aus irgendeinem Grund nicht mehr erreichbar ist.
- Konstruktive Hilfestellungen anbieten
- Fehlermeldungen dienen nicht nur dazu, Nutzer darauf aufmerksam zu machen, dass ein Fehler aufgetreten ist, sondern sie sollten dazu beitragen, den Fehler zu beheben.
Dieser Artikel betrachtet im Folgenden die in der Tabelle aufgeführten Fehler und gibt einige Hinweise zur Gestaltung der jeweiligen Fehlerseiten.
Gestaltung der Fehlerseiten
Die Standardfehlerseiten, die Browser anzeigen, wenn Sie keine eigenen Fehlerseiten definieren, geben kaum Hilfestellung, wie Nutzer an die gewünschten Informationen gelangen, und wirken aufgrund ihres reduzierten Designs wie ein Fremdkörper und nicht wie ein Teil Ihrer Website. Fehlerseiten sollten sich daher stets am Design Ihrer Website orientieren, also Kernelemente wie Logo, Site Label, grundlegenden Aufbau und Navigationsstruktur übernehmen. Besonders wichtig ist ein Link zur Homepage sowie zur Sitemap. Dadurch kann der Besucher sich schnell orientieren und die gesuchte Ressource vielleicht auf anderem Wege finden. Falls Ihrer Website aus mehr als nur einer Handvoll Seiten besteht, Sie allerdings keine Sitemap anbieten, dann erstellen Sie einfach eine! Jakob Nielsen verrät in seiner Alertbox Site Map Usability, wie eine solche auszusehen hat.
Ein Suchformular oder ein Link dorthin sollte auf keiner Fehlerseite fehlen. Das setzt natürlich voraus, dass Sie auf Ihrer Site eine Suchfunktion anbieten. Eventuell erfüllt die Einbindung einer externen Suchmaschine wie beispielsweise Google den gleichen Zweck, aber dann sollten Sie prüfen, ob alle von der Suchmaschine gelisteten URIs korrekt sind. Es wäre denkbar unglücklich, wenn ein Nutzer durch eine Trefferliste einer Suchmaschine auf Ihre Site gelangt und dort mit einer 404-Fehlerseite begrüßt wird, die ihn wieder zurück schickt.
Darüber hinaus gilt es, je nach Art des Fehlers, besondere Kriterien zu beachten.
401 – Unauthorized
Eine 401-Fehlerseite dient dazu, einen Nutzer aufzufangen, wenn er vergeblich versucht hat, sich mit Benutzernamen und Passwort auf einer Website anzumelden.
Stellen Sie sich vor, ein Nutzer klickt auf einen Link, der zu einem passwortgeschützten Bereich Ihrer Site verweist. Er wird sich mit hoher Wahrscheinlichkeit nicht anmelden können, den Anmeldedialog nach einigen Versuchen abbrechen und auf diesem Weg zur Fehlerseite gelangen. Oder ein bereits registrierter Nutzer hat seine Zugangsdaten vergessen bzw. das Passwort mehrfach falsch eingetippt. Wenn Sie sich nun in die Lage des ratlosen Nutzers hineinversetzen, kommen Sie schnell darauf, was eine 401-Fehlerseite enthalten sollte:
- Eine eindeutige Fehlermeldung,
- eine Erläuterung der Inhalte, die den Nutzer im passwortgeschützten Bereich erwarten, um ihm die Entscheidung zu ermöglichen, ob sich eine Anmeldung lohnt oder nicht,
- einen Link zur Anmeldung,
- einen Hinweis zur korrekten Eingabe der Benutzerdaten sowie
- die Möglichkeit, sich die Zugangsdaten erneut zusenden zu lassen.
403 – Forbidden
Fehler der Art 403 begegnen Ihnen, wenn Sie ein Verzeichnis aufrufen (http://www.example.com/foo/), in dem es keine Datei gibt, die als Verzeichnisindex angegeben ist (index.htm, index.html, index.php oder andere), also kein Dokument automatisch aufgerufen werden kann, und für das auch kein automatischer Verzeichnisindex angezeigt werden soll. Das Verzeichnis einer Website, in dem alle Grafiken abgelegt sind, ist ein Kandidat für ein solches Verzeichnis, denn in den meisten Fällen möchte man unerwünschten Besuchern derartige Einblicke »unter den Rock« der eigenen Website verwehren. Sie sollten in jedem Fall klar formulieren, dass der Zugriff auf das Verzeichnis nicht erlaubt ist und den Besucher stattdessen zu einem Besuch Ihrer Website »vor der Absperrung« einladen.
Einfach für Alle: So müssen hilfreiche 404-Fehlerseiten aussehen
404 – Not Found
Wer kennt das nicht? Man ruft eine Web-Ressource auf – und vollkommen unerwartet findet man sich im Niemandsland des Web wieder. Dafür kann es folgende Gründe geben:
- Der URI der Ressource wurde falsch eingetippt; entweder in der Adresszeile oder beim Anlegen des Links.
- Der Autor der Site wusste nicht, dass coole URIs sich nicht ändern und hat die Ressource gelöscht oder verschoben. Dadurch stimmen Lesezeichen, Links auf die Site sowie Einträge in Suchmaschinen nicht mehr.
404-Fehler entdecken und beheben
Fehler der Art 404 müssen Sie auf jeden Fall auffangen, schließlich handelt es sich dabei um die am häufigsten auftretende Art von Fehler im Web. Vorbildlich ist die 404-Fehlerseite der Initiative Einfach für Alle der Aktion Mensch (siehe Abbildung 1). Die Seite ist im Design der Website gehalten, schlägt einen sehr freundlichen Ton an und ist um konkrete Hilfestellung und Problemlösung bemüht.
Um stets auf dem Laufenden zu bleiben, welche 404er auf Ihrer Site auftreten, können Sie Ihre Besucher auf der Fehlerseite um eine Mail mit einer genauen Fehlerbeschreibung bitten, wie die 404-Fehlerseite der Initiative »Einfach für Alle« schön demonstriert – aber wie oft haben Sie eine solches Fehlerformular bereits ausgefüllt? –, oder Sie lassen sich (zusätzlich) bei jedem Aufruf der Fehlerseite eine automatisch generierte Mail zusenden. Letzteres ist wesentlich effektiver.
Viele moderne Programmiersprachen bieten Mailfunktionen, die beispielsweise bei Kontaktformularen eingesetzt werden, um die gesammelten Informationen an eine Mailadresse zu verschicken. Im folgenden Beispiel wird die PHP-Funktion mail() verwendet, um sich über jeden Zugriff auf die 404-Fehlerseite per Mail informieren zu lassen. Die Syntax der Funktion ist denkbar einfach:
mail ( string Empfänger, string Betreff, string Nachricht [, string Header [, string Parameter]]);
Empfänger enthält dabei die E-Mailadresse des Empfängers. Betreff stellt die Betreffzeile der E-Mail dar. Message enthält den eigentlichen Körper der Nachricht. Header ist optional und bietet die Möglichkeit, die Header-Informationen der E-Mail zu verändern. Ein vierter String Parameter kann seit PHP 4.0.5 unter Umständen dazu verwendet werden, zusätzliche Parameter an das Programm zu übergeben
Das folgende Beispiel-Skript verwendet für die ersten vier Argumente der Funktion eine Variable und stellt so die konkreten Inhalte, insbesondere den des Nachrichten-Körpers, individuell zusammen. Dabei hilft der Konkatenationsoperator (.=), den Quelltext übersichtlich zu gestalten. Mit ihm ist es möglich, zusätzliche Inhalte an das Ende eines in einer Variablen abgelegten Strings anzuhängen. Die Kommentare sollten für das Verständnis ausreichend sein.
Einzige Besonderheit ist die Verwendung von Server-Variablen, die allesamt in dem Array $_SERVER[] zur Verfügung stehen. In diesem Skript werden folgende Variablen verwendet:
$_SERVER["SERVER_NAME"]gibt den Servernamen zurück, (z.B.www.example.com),$_SERVER["REQUEST_URI"]gibt den aufgerufenen URI ausgehend vom Root-Verzeichnis zurück (z.B./index.html),$_SERVER["HTTP_USER_AGENT"]gibt den Identifikationsstring des User-Agents zurück (z.B.Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0) und$_SERVER["HTTP_REFERER"]schließlich gibt den URI des aufrufenden Dokuments zurück.
<?php
// Fehlercode
$fehlercode = "404";
// Adresse, an welche die E-Mail versendet werden soll
$empfaenger = "mail@example.com";
$betreff = "[" . $_SERVER["SERVER_NAME"] . "] Fehler " . $fehlercode;
// Nachricht zusammenbauen.
$message = "Auf der Website http://" . $_SERVER["SERVER_NAME"] . " ist ein Fehler " . $fehlercode . " aufgetreten.\n\n";
$message .= "Aufgerufene Ressource:\n";
$message .= "http://" . $_SERVER["SERVER_NAME"] . $_SERVER["REQUEST_URI"]."\n\n";
$message .= "User-Agent:\n";
$message .= $_SERVER["HTTP_USER_AGENT"];
if($_SERVER["HTTP_REFERER"] != "") {
$message .= "\n\nAufgerufen von der Adresse:\n";
$message .= $_SERVER["HTTP_REFERER"];
}
// Header-Informationen
$header = "From: Error Agent <erroragent@" . $_SERVER["SERVER_NAME"].">\n";
$header .= "Content-Type: text/plain";
// Mail zusammenstellen und absenden
@mail($empfaenger, $betreff, $message, $header);
?>
Das Feld From des E-Mail-Headers erwartet die Angabe der Mailbox des Absenders, also eine E-Mailadresse. Um dennoch einen Individuellen Absendernamen angeben zu können, ist folgende Notation notwendig:
From: Name <E-Mailadresse>
Das @ vor dem Aufruf der Funktion mail() bewirkt, dass Rückmeldungen, insbesondere Fehlermeldungen der Funktion, unterdrückt werden. Somit erhalten Sie auch dann keine störende Fehlermeldung, wenn auf localhost kein Mail-Server vorhanden oder etwas anderes schief gelaufen und PHP so konfiguriert ist, Fehler auf der Webseite auszugeben.
Dieses Skript funktioniert auch für andere Fehlercodes, beispielweise für Fehler der Art 403. In diesem Fall brauchen Sie nur den Wert der Variable $fehlercode zu ändern. Alternativ können Sie für mehrere Fehlerarten das gleiche Fehlerdokument verwenden, indem Sie dem URI bei der ErrorDocument-Direktive einen Parameter mitgeben und diesen der Variable $fehlercode zu Beginn des Skripts mit
$fehlercode = $_GET["errorcode"];
entsprechend zuweisen:
ErrorDocument 403 /error/document?errorcode=403 ErrorDocument 404 /error/document?errorcode=404
410 – Gone
Wenn Sie Ressourcen komplett aus Ihrer Website entfernt haben (natürlich nur, wenn es einen guten Grund gibt), sollten Sie keinen 404er, sondern Fehlercode 410 senden. Im Apache Webserver erreichen Sie dies über die Zeile
Redirect Gone /foo/bar
in der Zugriffskontrolldatei. Dadurch wird unmissverständlich klar, dass es die angeforderte Ressource unter diesem URI zwar mal gegeben hat, sie aber nicht aufgrund eines Versehens oder Fehlers vorübergehend nicht verfügbar ist, sondern bewusst aus dem Netz genommen wurde. Wählen Sie eine Formulierung wie »Das angeforderte Dokument ist nicht mehr verfügbar« oder ähnliches.
Danke für diese Anleitung. Der Artikel ist zwar schon 7 Jahre alt, aber immer noch aktuell.