Fehler-Seiten

Fehler-Meldungen des Apache Webservers

Es gibt mehrere Quellen (Herausgeber) von Fehler-Webseiten, z.B. Browser oder Webserver.

Auf dieser Seite finden sie Hinweise zur Organisation jener Fehlermeldungen, die vom Apache Webserver erzeugt werden.

Apache	Der weltweit erfolgreichste Standard Webserver (Linux, Windows)
Fehler-Meldungen	Text, Webseiten, Fehler-Programme
HTTP Status	Numerischer Status-Code und Fehler-Code
Fehler-Seiten	Anzeige von Browser- und Server-Fehlern auf Webseiten
LAN-Server	Eigene Fehler-Seiten am eigenen Webserver
Provider-Server	Eigene Fehler-Seiten am Provider-Webserver
error.html	Statische Fehler-Webseiten
error.php	Dynamische Fehler-Webseiten mit Perl, PHP, Python, ...
SSI	Dynamische Fehler-Webseiten mit Server-Side Includes
Links	Ausgewählte Links zum Thema 'Apache Fehler-Webseiten'

Fehlermeldungen am Webserver
Wenn der Webserver einen Fehler erkennt, dann gibt es 3 Möglichkeiten, eine Meldung an den Auftraggeber (Client, AnwenderIn, Browser) zu senden: • Einfacher Text (text/plain) • Eine lokale Webseite (vom gleichen Server verwaltet) • Eine externe Webseite Für Webseiten stehen noch die Varianten 'statisch' und 'dynamisch' zur Auswahl.	Varianten zur Meldung des Fehlers 404 'Seite nicht gefunden': # Text: # ErrorDocument 404 "Seite nicht gefunden !" # Statische Webseite am eigenen Server: ErrorDocument 404 /error_404.html # Fehler-Programm am eigenen Server: # ErrorDocument 404 "/cgi-bin/errprog.pl" # Seite auf einem entfernten Web: # ErrorDocument 402 http://provider.com/error/e404.html
Sie haben die Möglichkeit, Art und Umfang der Fehler-Meldungen genau an die jeweiligen Bedingungen anzupassen.	Die meist-verwendete Variante sind statische Webseiten am eigenen Server. Diese Variante ist als einzige im Beispiel oben nicht abgeschaltet.

HTTP Status Code
Ein Webserver sendet vor jedem Objekt (Webseite, Bild, ...) einen Block mit einigen Daten zur Ankündigung des angeforderten Objekts. Dieser → HTTP-Header dient zur Information des Browsers und wird auf normalen Webseiten nicht angezeigt. Ein wichtiger Bestandteil des HTTP-Headers ist der → HTTP Status (Response) Code. Der Code gibt in Form einer ganzen Zahl den 'Status' des nachfolgenden Objekts an. ♦ Die Seite → HTTP-Header dieses Webs bietet die Möglichkeit, den HTTP-Header ausgewählter Seiten Live anzuzeigen. ♦ Details (Liste) zum → HTTP Status Code	Zahlenwerte des HTTP Status Code: ● Zahlenwerte 100..199 betreffen allgemeine Informationen und sind in der Praxis unbedeutend. ● Zahlenwerte 200..299 betreffen erkannte und erfüllte Aufträge. Der häufigste Code 200 bedeutet "OK" und ist im HTTP-Header jeder korrekt angezeigten Webseite enthalten. ● Zahlenwerte 300..399 bezeichnen formal korrekte Aufträge, die jedoch unerfüllbar sind, z.B. umgesiedelte Webseiten. ● Zahlenwerte 400.499 bezeichnen Fehler-Meldungen. Der häufigste Code 404 bezeichnet 'Not found' - Die angeforderte Webseite wurde vom Server nicht gefunden. ● Zahlenwerte 500..599 bezeichnen interne Fehler des Webservers.
Wenn ein Webserver das angeforderte Objekt nicht liefern kann, dann sendet er an dessen Stelle eine Fehler-Webseite. Dabei handelt es sich meistens um sehr einfach aufgebaute Seiten.	Der → HTTP Status Code spielt eine wichtige Rolle bei der Auswahl der Fehler-Webseite.

Fehler-Webseiten
Die häufigste Ursache für die Anzeige von Fehler-Webseiten ist 'Seite nicht gefunden': Am Browser wurde eine Web-Adresse falsch eingetippt, oder der angeklickte Link wurde fehlerhaft formuliert, oder die angegebene Webseite existiert nicht mehr.	Die zweit-häufigste Fehler-Ursache sind fehlende Zugriffs-Rechte auf eine bestimmte Webseite. Beide Fehler werden vom Webserver erkannt, der eine entsprechende Fehlermeldung als Antwort-(Webseite) sendet.
Eine Fehler-Seite kann von verschiedenen 'Herausgebern' erzeugt werden, z.B. vom Webserver, vom → Router / Proxy-Server oder vom Browser. Auf dieser Seite wird die Organisation jener Fehler-Seiten vorgestellt, die vom → Apache Webserver erzeugt werden.	Fehlerseite vom Webserver Dieser Link erzeugt eine Fehlermeldung des Webservers von PS-Trainer: <a href="http://pstrainer.topsoft.at/nix.gut"> Fehler </a> Durch Anforderung einer nicht existierenden Webseite (z.B. nix.gut) kann man eine Fehler-Seite von jedem beliebigen Webserver provozieren.
Fehlerseite vom Browser Dieser Link führt zu einem hypothetischen Webserver an ihrem eigenen PC. Er sollte eine Fehler-Meldung ihres Browsers provozieren: <a href="127.0.0.1/nix.gut"> Fehler </a> Ausnahme: Wenn auf ihrem PC ein Webserver läuft. In diesem Fall geben sie eine Adresse ein, die innerhalb ihres lokalen Netzwerks (LAN) liegt, auf der jedoch mit Sicherheit kein Webserver läuft, oder die nicht vergeben ist, z.B. <a href="192.168.0.123/nix.gut"> Fehler </a>	Fehlerseite vom Router Es ist schwierig, genaue Angaben zu diesem Fall zu machen, da → Router (Proxy-Server) oft sehr unterschiedlich konfiguriert sind. Einige Möglichkeiten: ● Keine Verbindung zum Internet, keine Berechtigung (verschiedene Möglichkeiten), angeforderte Seite nicht gefunden, Browser falsch konfiguriert (Anforderung einer Seite des eigenen Webservers vom Router), usw.

Fehlermeldungen am eigenen Webserver
In diesem Kapitel werden Maßnahmen vorgestellt, welche eine Änderung der Webserver-Konfiguration erfordern. Das ist normalerweise nur am eigenen Webserver möglich. ♣ Tipp:Die vorgestellte Strategie erlaubt einen 'geordneten Rückzug' auf die Standard Fehler-Seiten, falls die eigenen Fehler-Seiten nicht wie erwartet funktionieren.	Wenn ihr Server lediglich zum Test eines Webs dient, welches später auf einen Provider-Server geladen wird, dann sollten sie nicht die hier vorgestellten Methoden verwenden, sondern die im nächsten Kapitel (↓ Provider-Webserver) angeführten.
Eigene Fehler-Seite(n): Legen sie ein eigenes Verzeichnis für ihre Webseiten an, am besten direkt neben dem Verzeichnis für die installierten Standard-Webseiten, z.B. /usr/share/apache2/my_error/ Legen sie in diesem Verzeichnis eine einzige Minimal-Webseite an, z.B. /usr/share/apache2/my_error/test.html Ändern sie erst dann die Konfiguration des Webservers. Löschen sie jedoch niemals die Original-Anweisungen, sondern schalten sie diese lediglich mit einem # führenden Kommentar-Zeichen ab.	♣ Tipp: Fehler-Seiten sind am besten autonom aufgebaut und verwenden keinerlei andere Resourcen (Bilder, CSS-Stylesheet-Dateien, Javascript-Bibliotheken, ...). Damit soll erreicht werden, dass zumindest diese Seiten unter allen Bedingungen korrekt angezeigt werden. Es ist kein Zufall, dass Fehler-Seiten meist spartanisch einfach aussehen. ♣ Wenn sie externe Resourcen verwenden, dann geben sie deren vollständige URL-Adressen an (http://...). Die bei allen anderen Webseiten verwendeten relativen Adressen funktionieren in diesem Fall nicht ! Test: Provozieren sie Fehler durch Anforderung nicht existierender Dateien aus 2 Verzeichnissen verschiedener Tiefe (z.B. aus einem Verzeichnis/Ordner und einem darin enthaltenen Sub-Verzeichnis).
Alias Alle Webseiten zur Fehler-Meldung fasst man sinnvoll in einem eigenen Verzeichnis (Ordner) zusammen. Zur Adressierung verwendet man nicht die vollständigen Pfade, sondern ein Alias. Vorteile: ▲ Eigene Fehler-Seiten werden in einem anderen Verzeichnis zusammengefasst. Zum Umschalten zwischen den Standard- und eigenen Fehler-Seiten genügt eine kleine Änderung des Alias. ▲ Um das gesamte Verzeichnis der Fehler-Seiten an einen anderen Pfad zu verschieben genügt ebenfalls eine Änderung des Alias. ♣ Tipp: Dieses Alias zeigt ihnen den Weg zu den installierten Standard-Webseiten an ihrem eigenen Webserver.	Typisches Alias für (statische) Fehler-Webseiten # Linux Alias /error/ "/usr/share/apache2/error/" # Windows # Alias /error/ "C:/Programme/.../Apache2.2/error/" Ein Alias (roter Text) ist ein Text-Macro, d.h. bei der Interpretation wird jedes identifizierte Alias durch den angegebenen Text ersetzt. Das Alias muss genauso verwendet werden wie definiert, d.h. in diesem Fall inklusive der beiden / Schrägstriche, z.B. so: ErrorDocument 404 /error/err404.html
ErrorDocument ► Mit der Option ErrorDocument wird für den jeweils angegebenen HTTP Status-Code die für diesen Fall zu sendende Webseite angegeben. ► Die Standard Fehler-Seiten *.html.var sind jeweils in mehreren Sprachen verfügbar. ► Eigene Webseiten organisiert man am besten in einem eigenen Verzeichnis, ohne die Originale zu ändern oder zu löschen. Sie sind meist auch nur in einer Version (Sprache) angelegt.	Typische Standard-Konfiguration auf Linux: Der Text /error/ ist ein ↑ Alias, welches vorher definiert wurde und den Pfad zu den Fehler-seiten weist: ErrorDocument 400 /error/HTTP_BAD_REQUEST.html.var ... ErrorDocument 500 /error/HTTP_ INTERNAL_SERVER_ERROR.html.var Änderung zur Verwendung eigener Webseiten: Alias /error/ "/home/test/my_error_pages" ErrorDocument 400 /error/err_400.html ... ErrorDocument 500 /error/err_500.html

Fehlermeldungen am Webserver eines Providers
In diesem Kapitel wird gezeigt, wie man selbst erstellte Fehler-Webseiten verwenden kann, wenn kein Zugriff auf die Konfiguration des Webservers möglich ist. Das trifft auf alle Webs zu, die von einem Web-Provider verwaltet werden. Alle halbwegs professionellen Provider bieten ihren KundInnen diese Möglichkeit. Die Basis-Konfiguration des Webservers bleibt dabei selbstverständlich unzugänglich. Einzelne Details können jedoch von den KundInnen individuell (nachträglich) angepasst werden.	Grund-Einstellung Hier werden zuerst jene Anweisungen vorgestellt, die in der (Grund)-Konfiguration des Webservers eingestellt werden: Die Server professioneller Provider sind bereits so eingestellt. Ändern sie die Konfiguration ihres eigenen Servers, um diese Konfiguration möglichst genau zu simulieren. Nachträgliche Änderung der Konfiguration Wenn die Voraussetzungen erfüllt sind, dann kann man die Konfiguration des Webservers nachträglich mit allen erlaubten Anweisungen ändern: • Wenn der Server in einem Verzeichnis (Ordner) eine Text-Datei namens .htaccess antrifft, dann wird die Konfiguration für dieses Verzeichnis und alle Unter-Verzeichnisse mit den in dieser Datei enthaltenen Anweisungen geändert.
AllowOverride In der Standard-Konfiguration wird zunächst jede Änderung der Server-Konfiguration für das gesamte Web-Verzeichnis verboten: AllowOverride None Um den Einsatz eigener FehlerSeiten zu erlauben, wird die nachträgliche Änderung der Server-Konfiguration in bestimmten Fällen erlaubt: AllowOverride FileInfo Sie ist normalerweise am Webserver des Providers so eingestellt. Stellen sie ihren eigenen Webserver ebenso ein, wenn sie das Verhalten des Provider-Servers simulieren wollen. Die nächste Zeile Allow from ... zeigt, wie man unabhängig davon den Zugang zum eigenen Webserver auf die PC des lokalen Netzwerks (hier 192.168.0.*) beschränken kann.	Standard-Konfiguration: <Directory "/srv/www/htdocs"> AllowOverride None Allow from all </Directory> So wird die nachträgliche Änderung der Konfiguration erlaubt: <Directory "/srv/www/htdocs"> AllowOverride FileInfo Allow from 192.168.0.0/255.255.255.0 </Directory>
AccessFileName In der Standard-Konfiguration von Apache wird festgelegt, dass Dateien mit dem Namen .htaccess zur nachträglichen Änderung der Konfiguration verwendet werden können. Danach wird mit Deny verboten, dass der Webserver eine dieser Dateien angezeigt.	AccessFileName .htaccess <Files ~ "^\.ht"> Order Allow,Deny Deny from all </Files>
Server-Neustart Der Webserver muss neu gestartet werden, damit ↑ Änderungen der Grund-Konfiguration wirksam werden. Kontrollieren sie danach die Log-Datei ! Alle weiteren ↓ nachträglichen Änderungen der Konfiguration erfordern keinen Neustart, d.h. solche Änderungen werden im betroffenen Verzeichnis Live berücksichtigt.	• Apache Neustart an einer Linux Shell-Konsole: (funktioniert an den meisten Linux-Systemen, ohne Gewähr). # /etc/init.d/apache2 restart • Apache Neustart auf einem Windows-PC: Verwenden sie das Programm im System-Tray (ganz rechts unten am Bildschirm, Icon rechts).
Test-Umgebung Zur Verwendung eigener Fehler-Seiten wird die Konfiguration des Webservers nachträglich geändert. • Diese Arbeit wird so einfach wie möglich geplant (rechts), um Fehler sofort zu finden und beseitigen. • Wenn alles funktioniert wie erwartet, dann werden im zweiten Schritt alle Fehler-Seiten in ihrer endgültigen Form erstellt und in der Test-Umgebung in Betrieb genommen. • Wenn auch dieser Test erfolgreich ist, werden sowohl die Konfigurations-Datei als auch die Fehler-Seiten aus der Test-Umgebung in das öffentliche Web übersiedelt.	● Legen sie in der obersten Ebene ihres Webs ( = wo sich die Start-Seite index.html befindet) ein Test-Verzeichnis an, z.B. mit dem Namen test Darin können sie experimentieren, ohne die Funktion aller anderen Webseiten zu stören. ● Legen sie im Test-Verzeichnis eine ganz einfache Webseite an, z.B. test/test.html Wenn die Änderung der Konfiguration klappt und im Test-Verzeichnis ein Fehler auftritt, dann soll diese Seite angezeigt werden. ● Legen sie im Test-Verzeichnis eine Text-Datei mit dem Namen test/htaccess.txt an. In diese Datei werden die ↓ Anweisungen zur Server-Konfiguration eingetragen. Danach wird die Datei umbenannt, Linux-formatiert und ihre Funktion getestet.
.htaccess Mit einer Text-Datei dieses Namens kann man die Konfiguration des Webservers für ein bestimmtes Verzeichnis (und alle Unter-Verzeichnisse) ändern. Voraussetzung Nachträgliche Änderungen sind mit der ↑ Option AllowOverride zugelassen. Diese Voraussetzung ist bei professionellen Web-Providern erfüllt und kann am eigenen Webserver genauso eingestellt werden. Der Name der individuellen Konfigurations-Datei muss auf .htaccess lauten. Der führende Punkt verhindert eine Anzeige dieser Datei in einer einfachen Verzeichnis-(directory)-Liste. ♣ Um auf Linux auch Dateien mit führendem Punkt anzuzeigen, verwenden sie Befehl ls mit Option -a # ls -a ♣ Windows hat Probleme, eine Datei dieses Namens zu erzeugen. Kopieren sie diese Datei von Linux auf Windows, oder: Legen sie auf Windows eine Text-Datei mit einem anderen Namen an (z.B. htaccess.txt), starten sie eine → Konsole (cmd.exe) und ändern den Namen, z.B. C:\> rename htaccess.txt .htaccess Die umbenannte Datei kann man auch auf Windows problemlos kopieren oder verschieben.	Als Verzeichnis-Pfad wird zunächst ein Test-Verzeichnis gewählt, danach normalerweise das Basis-Verzeichnis des Webs, d.h. jenes Verzeichnis, in welchem sich auch die 'Homepage' index.html befindet. Zusätzliche .htaccess Dateien in Unter-Verzeichnissen sind nur dann notwendig, wenn man für diese Verzeichnisse andere Optionen (andere Fehler-Seiten) festlegen will. Der Inhalt der Datei besteht aus reinem Text (text/plain). Die Syntax (Grammatik) folgt den gleichen Regeln wie für die Standard-Konfiguration. Der Text einer .htaccess Datei ändert oder ergänzt die geltende Konfiguration des bereits laufenden Webservers. Der Text kann jedes beliebige Detail der Konfiguration betreffen. In diesem Kapitel werden jedoch nur jene Optionen vorgestellt, welche Fehler-Webseiten betreffen. Als Text-Format der Datei verwenden sie die Linux-Variante, da die meisten Webserver auf Linux-Systemen laufen. In diesem Fall wird jede Zeile mit LF = 0x0A abgeschlossen (nicht wie auf Windows mit CRLF = 0x0D0A ). Allerdings sind die meisten Server tolerant und akzeptieren beide Versionen. Ein guter Text-Editor wie Notepad++ bietet u.a. diese Option.
Test-Konfiguration Wenn alle oben genannten Voraussetzungen erfüllt sind, dann wird eine Konfigurations-Anweisung in die Text-Datei .htaccess eingetragen: ErrorDocument 404 /test/test.html Wenn (im Test-Verzeichnis) ein Fehler 404 auftritt (Datei nicht gefunden), dann soll der Webserver die bezeichnete Webseite senden. Der Pfad wird relativ zum Start-Verzeichnis angegeben (am eigenen Server DocumentRoot).	Test Provozieren sie einen Fehler 404 im Test-Verzeichnis, z.B. durch Eingabe einer nicht vorhandenen Adresse, die jedoch im Test-Verzeichnis gesucht werden muss, z.B. http://localhost/test/nixgut.html ● Bei erfolgreicher Konfiguration sollte die umgeleitete Webseite angezeigt werden. Anschließend wird die Lösung sinngemäß in das Start-Verzeichnis des gesamten Webs übersiedelt. ● Wenn die Umleitung nicht funktioniert, dann prüfen sie nochmals jedes Detail der durchgeführten Arbeiten und lesen sie das Error-Log des Servers. Die häufigsten Fehler sind falsch formulierte Pfade.
Endgültige Konfiguration Wenn der ↑ Test mit einer einzelnen Fehler-Seite erfolgreich absolviert wurde, dann kann man die Lösung auf das gesamte Web und auf alle Fehlermeldungen übertragen. Verzeichnis der Fehler-Seiten Legen sie im Start-Verzeichnis des Webs ein neues Verzeichnis zur Aufnahme aller Fehler-Seiten an, z.B. /srv/www/htdocs/err Endgültige Fehler-Seiten Legen sie im genannten Verzeichnis je eine Fehler-Webseite für jeden nach HTTP-Standard möglichen Fehler an, z.B. /srv/www/htdocs/err/err_300.html ... /srv/www/htdocs/err/err_404.html ... /srv/www/htdocs/err/err_505.html Zugangs-Rechte Stellen sie die Zugangs-Rechte zum Verzeichnis und allen darin enthaltenen Dateien so ein, dass sie vom Webserver gelesen werden dürfen, z.B. # chmod -R 744 /srv/www/htdocs/err	Konfiguration Kopieren sie die Datei .htaccess aus dem Test-Verzeichnis in das Start-Verzeichnis und ändern sie den Text der Anweisung zunächst nur für einen Fehler: ErrorDocument 404 /err/err_404.html Test Testen sie die Konfiguration durch Anforderung einer nicht existierenden Webseite (jedoch nicht aus dem vorher verwendeten Test-Verzeichnis), z.B. http://localhost/nix/gutt.html Abschluss ● Wenn der Test erfolgreich war und ihre eigene Fehler-Seite angezeigt wurde, dann wird die Konfigurations-Datei .htaccess mit je einer Zeile für jede Fehler-Seite ergänzt; ErrorDocument 400 /err/err_300.html # ... ErrorDocument 404 /err/err_404.html # ... ErrorDocument 500 /err/err_505.html Damit ist diese Arbeit abgeschlossen: Alle HTTP-Fehler werden nun mit ihren eigenen Fehler-Webseiten angezeigt.

Statische HTML Fehler-Webseiten
Die Verwendung statischer Webseiten (*.html Dateien) ist die einfachste und sicherste Variante eigener Fehler-Webseiten. Wenn sie nur eine einzige Fehler-Seite einsetzen (z.B. error.html), dann lässt sich darauf nur eine allgemeine Fehler-Meldung unterbringen, jedoch keine Informationen zur Art des aufgetretenen Fehlers. Diese Variante eignet sich daher nur als Test während der Konfiguration. Typische Konfiguration (hier für 3 ausgewählte Fehler-Codes): ErrorDocument 400 /error.html ErrorDocument 404 /error.html ErrorDocument 500 /error.html	Alle Fehler-Seiten sollten möglichst autonom aufgebaut sein und keinerlei andere Resourcen (Bilder, CSS-Stylesheet-Dateien, Javascript-Bibliotheken, ...) verwenden. Sie sollten entweder gar keine Links enthalten, oder nur Links mit vollständiger URL-Adresse (http://...) zu solchen Seiten, die voraussichtlich nicht gelöscht, verschoben oder umbenannt werden, z.B. eine Homepage: <a href="http://pstrainer.topsoft.at"> Homepage von PS-Trainer </a> Mit diesen Maßnahmen soll erreicht werden, dass zumindest die Fehler-Seiten unter allen Bedingungen korrekt funktionieren.
Der häufigste Fall ist die Verwendung mehrerer Fehler-Webseiten. Jede Seite ist auf einen bestimmten HTTP Status-(Fehler)-Code spezialisiert. Aus praktischen Gründen enthält der Datei-Name am besten auch den jeweiligen Fehler-Code. Wenn alle Fehler-Seiten im Basis-Verzeichnis (ebenso wie die Startseite index.html) untergebracht sind, dann lautet eine typische Konfiguration z.B. ErrorDocument 400 /error_400.html ErrorDocument 404 /error_404.html ErrorDocument 500 /error_500.html	Mehrere Fehler-Seiten werden zur besseren Übersicht meist in einem eigenen Verzeichnis zusammengefasst. Dazu wird meist ein Alias error angelegt, welches (ausgehend vom Verzeichnis DocumentRoot zum Verzeichnis der Fehler-Seiten führt. In diesem Fall lautet die typischen Konfiguration z.B. ErrorDocument 400 /error/error_400.html ErrorDocument 404 /error/error_404.html ErrorDocument 500 /error/error_500.html

Dynamische Fehler-Webseiten (Perl, PHP, Python, ...)
Dynamische Webseiten können bei richtiger Verwendung mehr Information anzeigen als statische Seiten. Außerdem ist es möglich, alle Fehler mit einem einzigen Programm (z.B. error.php ) zu verarbeiten: Die Seite wird dynamisch an die jeweilige Fehler-Meldung angepasst. Die Verwendung dynamischer Webseiten erhöht allerdings das Risiko: Wenn in einem Script-Programm ein Fehler auftritt, dann erhält ihr/e BesucherIn an Stelle einer Fehler-Meldung eine verstümmelte, fehlerhafte oder gar keine Fehler-Webseite. Daher sind die Ansprüche an die Programmierung dynamischer Fehler-Seiten besonders hoch: Versuchen sie, alle denkbaren Fehler abzufangen, selbst wenn sie die Wahrscheinlichkeit dafür mit Null einschätzen. Darüber hinaus gelten die Regeln für statische Fehler-Seiten, d.h. die Programme sollten autonom arbeiten und keinerlei externe Resourcen verwenden.	Dynamische Webseiten sind nur dann sinnvoll, wenn ihre Vorteile tatsächlich in Anspruch genommen werden, d.h. wenn sie mehr sinnvolle Information anzeigen als statische Seiten. Der → Apache Webserver definiert zu diesem Zweck einige zusätzliche Umgebungs-Variablen - Diese Variablen sind nur dann gültig, wenn unmittelbar vorher ein Fehler auftrat. Eine dynamische Fehler-Webseite verwendet diese Daten zur besseren Information der/des BesucherIn. Die folgenden Beispiele demonstrieren die Verarbeitung mit der Programmiersprache → PHP. Sie gelten in leicht modifizierter Form auch für Programme in → Java, → Perl, Python, usw.
Array $_SERVER Dieses → Globale Array enthält die meisten Daten zur Gestaltung dynamischer Fehler-Seiten. Das Element $_SERVER['REQUEST_URI'] enthält jene Anforderung, die zum Fehler führte, z.B. $_SERVER['REQUEST_URI'] = /nix.gut Das Element $_SERVER['REDIRECT_STATUS'] enthält den HTTP Status-(Fehler)-Code, z.B. $_SERVER['REDIRECT_STATUS'] = 404 ♦ Details zur Umgebung von PHP-Programmen und zu Globalen Arrays.	Darüber hinaus enthält das Array $_SERVER einige weitere Variable, deren Namen mit REDIRECT_ beginnen. Allerdings werden diese Elemente nicht bei jedem Fehler definiert. So erhalten sie eine Liste aller definierten REDIRECT- Variablen: foreach($_SERVER as $n=>$v) { if(ereg("^REDIR",$n)) { print "\$_SERVER['$n'] = $v <br />\n"; } } So können sie feststellen, ob eine bestimmte REDIRECT-Variable definiert wurde: if(array_key_exists('REDIRECT_STATUS',$_SERVER)) { $rs = $_SERVER['REDIRECT_STATUS']; print "REDIRECT_STATUS = $rs<br />\n"; } ♦ Details zu Arrays @ PHP
Absolute oder URL-Pfade ! Eine Fehler-Seite darf nur vollständige URL-Pfade (http://...) enthalten. Das gilt insbesondere für Bibliotheken (.css, .js, .php, ...), Grafik (.gif, .jpeg, .png, *.svg ...), in Rahmen (<frame>, <iframe>, ...) eingebettete Objekte usw.	♣ Vermeiden sie nach Möglichkeit alle Bezüge auf andere Dateien. Wenn das nicht möglich ist, dann geben sie absolute Pfade oder Web-Adressen an - auch dann, wenn diese in Verzeichnisse des gleichen Webservers weisen. Achtung: Sowohl die absoluten Pfade als auch die URL-Adressen unterscheiden sich normalerweise am eigenen Webserver und an jenem des Providers ! - Erstellen sie in diesem Fall besser eigene Fehler-Seiten für jeden der beiden Server.

Dynamische Fehler-Webseiten mit SSI
Die Anwendung von → Server-Side Includes (SSI) ermöglicht vor allem am eigenen Webserver die einfache Herstellung von dynamischen Fehler-Webseiten. Sie werden zweckmäßig aus 2 fixen Teilen (top.html, bot.html) und variablen Mittelteilen zusammengesetzt. Die Dateien zu den einzelnen Fehler-Meldungen sind dann sehr klein (Beispiel rechts).	Beispiel einer kompletten Fehler-Seite error_404.html <!--#include virtual="top.html" --> Objekt nicht gefunden:<br /> <!--#echo var="REQUEST_URI"--> <!--#include virtual="bot.html" -->
Die Datei top.html enthält den gesamten HTML-Code bis zum Beginn des Erklärungs-Textes, d.h. die HTML-Deklaration, das komplette <head>-Element mit der → CSS-Formatierung, und meist auch einen Teil des <body>-Elements. Auch die beiden statischen Dateien können SSI-Elemente enthalten, hier z.B. die Ausgabe des HTTP Fehler-Codes REDIRECT_STATUS	Beispiel für eine Datei top.html <html> <head> <title> Fehler <!--#echo var="REDIRECT_STATUS"--> </title> <style>...</style> </head> <body> <h1> Fehler <!--#echo var="REDIRECT_STATUS"--> </h1>
Die Datei bot.html enthält den gesamten abschließenden HTML-Code. Im Beispiel sind Links zur letzten Webseite (mit → Javascript) und zur Server-Startseite (mit → SSI) eingefügt.	Beispiel für eine Datei bot.html <a href="javascript:history.back()"> Zurück</a> zur letzten Webseite.<br /> Zur <a href="/">http://<!--#echo var="SERVER_ADDR"--></a> Server-Startseite. </body> </html>
Apache Konfiguration Eine Voraussetzung für diese Methode ist die passende Konfiguration des Apache Webservers. • Das Apache-Modul include muss geladen sein. • Ersetzen sie den Pfad (/srv/www/error) durch den Pfad zu ihren selbst erstellten Fehler-Seiten. • Die Option IncludesNoExec erlaubt die Ausführung von SSI. • Das OutputFilter wendet SSI auf alle enthaltenen Dateien *.html an. • Ergänzen sie die ... der Liste für alle angelegten Fehler-Dateien.	Beispiel für eine Datei myerror.conf Alias /error/ "/srv/www/error/" <Directory "/srv/www/error"> AllowOverride None Options IncludesNoExec AddOutputFilter Includes html Order allow,deny Allow from all </Directory> ErrorDocument 400 /error/error_400.html ... ErrorDocument 506 /error/error_506.html
♦ Details zu Server-Side Includes (SSI)

Ausgewählte Links zum Thema 'Apache Fehler-Seiten'

Apache-Manual

Ein eigener Apache Webserver bietet normalerweise das gesamte Manual unter dem Alias /manual/
Beispiel: http://localhost/manual/
Hier finden sie zahlreiche Details, u.a. zu allen Themen dieser Seite (die folgenden Links arbeiten nur auf ihrem eigenen Webserver !):
AccessFileName, Alias, AllowOverride, ErrorDocument, ErrorLog, ...
Das Manual ist auch Online auf der Apache Homepage verfügbar.

Zahlreiche weitere Hinweise und Artikel finden sie bei der Suche nach diesen Stichworten (und Kombinationen davon):

apache, fehler oder error, errordocument, ...

Zum Inhaltsverzeichnis

> System > Server > Apache