Verwenden detaillierter HTTP-Fehler in IIS 7.0

vom IIS-Team

Einführung

Die Meldungen „404 – Datei nicht gefunden“, „401 – Nicht autorisiert“ oder „500 – Serverfehler“ sind allen Websiteadmins und Webentwicklern und Webentwicklerinnen im Browser nicht fremd. In diesem Artikel erfahren Sie, wie und warum IIS diese Fehler generiert und wie sie konfiguriert werden können.

Viele mögen denken, dass die Erzeugung von Fehlermeldungen keinen ganzen Artikel rechtfertigt. Aber hinter den Fehlern steckt mehr, als man auf den ersten Blick sieht. Fehlermeldungen sind ein heikles Thema, denn jeder Fehler verrät mehr über Ihre Website, als Sie vielleicht wollen. Je mehr Informationen jemand über Ihre Website sammeln kann, desto wahrscheinlicher ist es, dass Sie gehackt werden. Eine Suche nach „Google Hacking“ oder „Cross-Site Scripting“ liefert eine Fülle von Informationen zu diesem Thema.

Fehlermeldungen sind jedoch auch ein wertvolles Tools zur Problembehandlung. Entwicklerinnen und Entwickler sowie Websiteadmins benötigen so viele Details wie möglich, wenn ein Fehler auftritt. Im Idealfall enthält die Fehlermeldung Empfehlungen, wie Sie das Problem beheben können. Hier erfahren Sie, wie das IIS diese grundlegend gegensätzlichen Ziele angeht.

Fehler, welche Fehler?

Dieser Artikel befasst sich mit HTTP-Fehlern, wie sie im HTTP RFC (RFC 2616 – Abschnitt 6.1.1) beschrieben sind. Ein HTTP-Fehler wird immer dadurch ausgedrückt, dass eine Antwort mit einem Statuscode größer als 400 an den anfragenden Client zurückgeschickt wird.

Clientfehler

Statuscodes zwischen 400 und 500 geben einen Fehler an, den der Client gemacht hat, z. B. eine fehlerhafte Syntax oder eine Anforderung an eine Ressource, die nicht existiert. Sie können dies versuchen, indem Sie eine unechte URL von der Website Ihrer Wahl anfordern, zum Beispiel: http://<IIS7Server>/this_resource_does_not_exist. Es wird ein Fehler „404 – Datei nicht gefunden“ angezeigt.

Serverfehler

Statuscodes, die mit 500 beginnen, sind vom Server verursachte Fehler. Die häufigsten Ursachen für 500-Fehler auf IIS-Systemen sind:

• Eine ASP- oder ASPX-Seite, die einen Syntaxfehler enthält
• Die Webserverkonfiguration oder die Anwendungskonfiguration kann nicht gelesen werden oder ist ungültig
• Die Website wurde beendet

Es ist wichtig zu wissen, dass Browser wie der IE oft Fehler, die von einem Webserver zurückgegeben werden, durch eigene Fehler ersetzen. Dadurch wird die Problembehandlung erschwert. In IE können Sie dieses Feature deaktivieren. Wechseln Sie zum Menü „Extras“, wählen Sie „Internetoptionen“ aus, klicken Sie auf die Registerkarte „Erweitert“, und suchen Sie das Kontrollkästchen „Benutzerfreundliche HTTP-Fehlermeldungen anzeigen“, und deaktivieren Sie es. Um die unbearbeitete Antwort zu sehen, verwenden Sie HTTP-Tools wie WFETCH aus dem IIS 6.0 Resource Kit (weitere Informationen finden Sie unter „Verwandte Links“).

HTTP-Fehler in IIS

Wenn das httpError-Modul (custerr.dll) auf einen Fehler stößt, können zwei Dinge passieren:

• Es wird ein benutzerdefinierter Fehler generiert.
• Es wird ein detaillierter Fehler generiert.

Benutzerdefinierte Fehler sind Fehlerseiten, die die normalen Benutzerinnen und Benutzer Ihrer Website sehen. Sie enthalten eine kurze Fehlerbeschreibung, warum der Fehler aufgetreten ist, aber sonst nichts. Hier finden Sie den benutzerdefinierten Fehler, der erzeugt wird, wenn Sie eine Ressource anfordern, die nicht existiert, z. B.: http://<IIS7Server>/this_resource_does_not_exist

Detaillierte Fehler sind für lokale Admins und Entwicklerinnen und Entwickler vorgesehen. Sie sollen Informationen bereitstellen, mit denen das Problem sofort behoben werden kann. Hier ist ein Beispiel für dieselbe Anforderung, aber mit einem detaillierten Fehler:

Dies ist gefährlich, da detaillierte Fehler Informationen über das Innenleben Ihrer Website enthalten. Nur vertrauenswürdige Personen sollten einen detaillierten Fehler sehen. Die einzige Möglichkeit, dies zu gewährleisten, besteht darin, nur dann einen detaillierten Fehler zu erzeugen, wenn die Anforderung vom lokalen Computer stammt. Sobald die Anforderung nicht lokal ist, wird ein benutzerdefinierter Fehler generiert. Sehen Sie sich das folgende Flow-Diagramm an:

Datenfluss

Erstens: Fehlerüberprüfung

Das httpError-Modul erhält eine Benachrichtigung, wenn eine Antwort gesendet werden soll (RQ_SEND_RESPONSE-Benachrichtigung). Das httpError-Modul prüft den Statuscode dieser Antwort und antwortet sofort, wenn der Statuscode nicht größer als 400 ist.

Zweitens: Benutzerdefinierter Fehler oder detaillierter Fehler

Die nächste Prüfung wird durch die Herkunft der Anforderung (kommt die Anforderung von einem lokalen oder einem Remotegerät) und die Einstellung der Eigenschaft errorMode bestimmt. Die Eigenschaft errorMode ist auf DetailedLocalOnly eingestellt, was bedeutet, dass für jede Anforderung von einem Remotegerät benutzerdefinierte Fehler erzeugt werden. Wenn errorMode auf „Custom“ eingestellt ist, werden alle Fehlerantworten zu benutzerdefinierten Fehlern. Wenn errorMode auf „Detailed“ festgelegt ist, werden alle Fehlerantworten zu detaillierten Fehlern. In der folgenden Tabelle wird dieses Verhalten erläutert:

Wenn das httpError-Modul feststellt, dass ein benutzerdefinierter Fehler erzeugt werden muss, prüft es in seiner Konfiguration, ob es einen passenden Fehler finden kann. Wenn eine Übereinstimmung gefunden wird, sendet es die statische Datei, leitet die Anforderung um oder führt die angegebene URL aus. Wenn keine Übereinstimmung gefunden wird, sendet der IIS eine einfache einzeilige Meldung mit dem Statuscode. Im nächsten Abschnitt wird die Konfiguration für benutzerdefinierte Fehler ausführlich erläutert.

Wenn custerr.dll feststellt, dass ein detaillierter Fehler erzeugt werden muss, ist eine weitere Prüfung erforderlich. Der IIS ändert die Antwort nicht, wenn ein Modul die Entität der Antwort mit einer eigenen Fehlerbeschreibung überschrieben hat. Sie kann wertvolle Informationen enthalten. ASP.NET ist ein gutes Beispiel. Die Entität einer ASP.NET Fehlerantwort kann den Ausnahmestapel und seine eigene Fehlerbeschreibung enthalten. Ein detaillierter Fehler wird nur generiert, wenn der Entitätstext der Antwort leer ist.

<httpErrors> Konfiguration

Nachfolgend sehen Sie den benutzerdefinierten IIS-Fehlerabschnitt für eine Neuinstallation:

<httpErrors>
    <error statusCode="401" prefixLanguageFilePath="c:\inetpub\custerr" path="401.htm" />
    <error statusCode="403" prefixLanguageFilePath="c:\inetpub\custerr" path="403.htm" />
    <error statusCode="404" prefixLanguageFilePath="c:\inetpub\custerr" path="404.htm" />
    <error statusCode="405" prefixLanguageFilePath="c:\inetpub\custerr" path="405.htm" />
    <error statusCode="406" prefixLanguageFilePath="c:\inetpub\custerr" path="406.htm" />
    <error statusCode="412" prefixLanguageFilePath="c:\inetpub\custerr" path="412.htm" />
    <error statusCode="500" prefixLanguageFilePath="c:\inetpub\custerr" path="500.htm" />
    <error statusCode="501" prefixLanguageFilePath="c:\inetpub\custerr" path="501.htm" />
    <error statusCode="502" prefixLanguageFilePath="c:\inetpub\custerr" path="502.htm" />
</httpErrors>

Sie sehen, dass IIS eine Datei mit dem Namen 401.htm zurückgibt, wenn der Statuscode einer Antwort 401 lautet.

Unterstatuscodes

Viele HTTP-Fehler haben einen Unterstatus. Die IIS-Standardkonfiguration für benutzerdefinierte Fehler unterscheidet nicht nach Unterstatuscodes. Sie sendet dieselbe benutzerdefinierte Fehlerseite, wenn Sie die falschen Anmeldedaten eingeben (401.1) oder wenn Ihnen der Zugriff auf eine Datei aufgrund ungültiger Rechte verweigert wird (401.3). Sie können die verschiedenen Unterstatuscodes in den Protokolldateien oder über detaillierte Fehler einsehen. Hier ist eine Liste der verschiedenen 404-Unterstatuscodes, die IIS erzeugt:

Sie können den Abschnitt „httpErrors“ so konfigurieren, dass ein benutzerdefinierter Fehler für bestimmte Unterstatuscodes angezeigt wird. Wenn Sie die folgende Zeile zum Konfigurationsabschnitt httpErrors hinzufügen, gibt IIS 404_3.htm zurück, wenn eine Datei mit einer Dateierweiterung angefordert wird, die nicht in der IIS MimeMap enthalten ist (Konfigurationsabschnitt <staticContent>).

<error statusCode="404" subStatusCode="3" prefixLanguageFilePath="c:\inetpub\custerr" path="404_3.htm" />

Hier sehen Sie, wie Sie das Beispiel umsetzen können:

1. Fügen Sie den obigen Eintrag zu Ihrem Konfigurationsabschnitt httpErrors hinzu.
2. Erstellen Sie eine Datei mit dem Namen 404_3.htm in Ihrem Verzeichnis c:\inetpub\custerr\en-us.
3. Erstellen Sie eine Datei mit dem Namen test.yyy in Ihrem Verzeichnis c:\inetpub\wwwroot.
4. Fordern Sie jetzt http://localhost/test.yyy an.

Die Dateierweiterung yyy ist nicht Teil der IIS MimeMap, und der statische Dateihandler wird sie nicht bedienen.

Neu in IIS: Sprachspezifische benutzerdefinierte Fehler

Jeder neuere Browser enthält die Sprache des Clients als Anforderungheader. Hier ist ein Beispiel dafür, wie dieser Header aussehen kann:

Accept-Language: en-us

Die Syntax und Registrierung der akzeptierten Sprachen wird in RFC1766 angegeben.

Beim Generieren eines Fehlers berücksichtigt IIS diesen Header, wenn er nach der zurückzugebenden benutzerdefinierten Fehlerdatei sucht. Er generiert den Pfad für den benutzerdefinierten Fehler mithilfe der folgenden Logik:

Konfigurationseinstellung prefixLanguageFilePath (z. B. c:\inetpub\custerr)+
Vom Client gesendeter Accept-Language-Header (z. B. en-us)+
Pfadkonfigurationseinstellung (z. B. 404.htm)

Beispiel:

Wenn der Browser eine Anforderung für eine nicht existierende Ressource sendet und der „Accept-Language“-Header den Wert „en-us“ hat, wird die Datei c:\inetpub\custerr\en-us\404.htm zurückgegeben.

Wenn Sie z. B. aus Deutschland sind, möchten Sie Ihre Fehlermeldungen auf Deutsch. Dazu müssen Sie das Windows Vista Language Pack für Deutsch installieren. Dadurch wird das Verzeichnis c:\inetpub\custerr\de-DE mit benutzerdefinierten Fehlerdateien erstellt. Wenn der Browser nun den Header „Accept-Language“ mit dem Wert „de-DE“ sendet, wird die Datei c:\inetpub\custerr\de-DE\404.htm zurückgegeben.

Wenn das Verzeichnis „de-DE“ nicht existiert, greift IIS immer auf die Systemsprache zurück.

Optionen für benutzerdefinierte Fehler

In den Beispielen oben sendet IIS den Inhalt der Datei als benutzerdefinierte Fehlerantwort. IIS hat zwei andere Möglichkeiten, auf einen Fehler zu reagieren: durch Ausführen einer URL oder durch Umleiten der Anforderung.

ExecuteUrl

Wenn Sie mit Ihrem benutzerdefinierten Fehler mehr tun möchten, z. B. eine E-Mail senden oder den Fehler in einer Datenbank protokollieren, können Sie eine URL ausführen. Auf diese Weise können Sie dynamische Inhalte wie eine ASP.NET Seite ausführen. Im folgenden Beispiel wird der benutzerdefinierte Fehler 404 ersetzt. IIS führt jetzt /404.aspx aus, wenn ein 404-Fehler auftritt.

<httpErrors>
<!-- default custom error for 401 errors -->
<!-- <error statusCode="404" prefixLanguageFilePath="c:\inetpub\custerr" path="404.htm" />-->

<!-- ExecuteURL replaces default file response mode -->
<error statusCode="404" path=/404.aspx" responseMode="ExecuteURL"/>        
<error statusCode="403" prefixLanguageFilePath="c:\inetpub\custerr" path="403.htm" />
<error statusCode="404" prefixLanguageFilePath="c:\inetpub\custerr" path="404.htm" />
<error statusCode="405" prefixLanguageFilePath="c:\inetpub\custerr" path="405.htm" />
<error statusCode="406" prefixLanguageFilePath="c:\inetpub\custerr" path="406.htm" />
<error statusCode="412" prefixLanguageFilePath="c:\inetpub\custerr" path="412.htm" />
<error statusCode="500" prefixLanguageFilePath="c:\inetpub\custerr" path="500.htm" />
<error statusCode="501" prefixLanguageFilePath="c:\inetpub\custerr" path="501.htm" />
<error statusCode="502" prefixLanguageFilePath="c:\inetpub\custerr" path="502.htm" />

</httpErrors>

Sicherheitshinweise

Ein Hinweis: Aus Architekturgründen kann IIS die URL nur ausführen, wenn sie sich im selben Anwendungspool befindet. Verwenden Sie das Umleitungsfeature, um einen benutzerdefinierten Fehler in einem anderen Anwendungspool auszuführen.

IIS kann auch eine 302-Umleitung an den Browser zurückgeben, wenn ein bestimmter Fehler auftritt. Die Umleitung ist nützlich, wenn Sie eine Serverfarm haben. So können Sie beispielsweise alle Fehler an einen zentralen Ort umleiten, den Sie genau überwachen.

Es gibt jedoch ein Risiko: responseMode="File" (die Standardeinstellung) ermöglicht es Ihnen, jede Datei auf dem Datenträger anzugeben. Dies wird nicht funktionieren, wenn Sie sehr sicherheitsbewusst sind.

Ein praktikables Szenario könnte darin bestehen, nur die Delegierung der errorMode-Einstellung zuzulassen. Dies ermöglicht es einem Entwickler bzw. einer Entwicklerin, detaillierte Fehler für Anwendung zu erhalten, auch wenn ein Remoteclient verwendet wird. Es ist lediglich erforderlich, errorMode="Detailed" einzustellen. Hier erfahren Sie, wie Sie dieses Szenario konfigurieren:

Die Delegation des Bereichs httpErrors zulassen:

<section name="httpErrors" overrideModeDefault="Allow" />

Gehen Sie anschließend zum Abschnitt <httpErrors> in applicationHost.config und ändern Sie ihn so, dass nur errorMode delegiert wird:

<httpErrors lockAllAttributesExcept="errorMode" lockElements="error">
    <error statusCode="404" prefixLanguageFilePath="E:\inetpub\custerr" path="404.htm" />
    <error statusCode="401" prefixLanguageFilePath="E:\inetpub\custerr" path="401.htm" />
    <error statusCode="403" prefixLanguageFilePath="E:\inetpub\custerr" path="403.htm" />
    <error statusCode="405" prefixLanguageFilePath="E:\inetpub\custerr" path="405.htm" />
    <error statusCode="406" prefixLanguageFilePath="E:\inetpub\custerr" path="406.htm" />
    <error statusCode="412" prefixLanguageFilePath="E:\inetpub\custerr" path="412.htm" />
    <error statusCode="500" prefixLanguageFilePath="E:\inetpub\custerr" path="500.htm" />
    <error statusCode="501" prefixLanguageFilePath="E:\inetpub\custerr" path="501.htm" />
    <error statusCode="502" prefixLanguageFilePath="E:\inetpub\custerr" path="502.htm" />
</httpErrors>

Zusammenfassung

Benutzerdefinierte und detaillierte Fehler sind leistungsstarke IIS-Features. Sie helfen Ihnen bei der Problembehandlung, ohne die Sicherheit Ihres IIS-Servers zu gefährden. Viele Konfigurationsoptionen helfen Ihnen dabei, die Erfahrung Ihrer Benutzerinnen und Benutzer individuell anzupassen. Das Wichtigste: Das Experimentieren damit macht Spaß.

Weitere Informationen

• Problembehandlung häufiger IIS-Fehler