Fehlerseiten mit Apache und PHP
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:
[code gutter=“false“]
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
[/code]
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.
Der Artikel Eigene Fehlerseiten gestalten von Michael Jendryschik geht mehr auf die Gestaltung der Fehlerseiten und einige Richtlinien ein.