Fehlerprotokollierung in HTTP-APIs

  • Artikel

In diesem Artikel werden die Fehlerprotokollierungsfunktionen von HTTP-APIs (HyperText Transfer Protocol) beschrieben.

Ursprüngliche Produktversion: Windows Server 2008 R2, Windows Server 2008, Windows Server 2012 R2, Windows Server 2012, Windows 10, Windows 8.1
Ursprüngliche KB-Nummer: 820729

Zusammenfassung

Einige Fehler, die in einer HTTP-basierten Anwendung auftreten, werden automatisch von der HTTP-API behandelt, anstatt zur Behandlung an eine Anwendung zurückgegeben zu werden. Dieses Verhalten tritt auf, weil die Häufigkeit solcher Fehler andernfalls ein Ereignisprotokoll oder einen Anwendungshandler überflutet.

In den folgenden Themen werden die verschiedenen Aspekte der HTTP-API-Fehlerprotokollierung beschrieben.

Die folgenden Methoden beschreiben die Auflösung der HTTP-API-Fehlerprotokollierung.

Konfigurieren der HTTP-API-Fehlerprotokollierung

Drei Registrierungswerte unter einem HTTP\Parameters-Schlüssel steuern die HTTP-API-Fehlerprotokollierung. Diese Schlüssel befinden sich im Registrierungsschlüssel: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters.

Hinweis

Der Speicherort und die Form der Konfigurationswerte können sich in späteren Versionen des Windows-Betriebssystems ändern.

Sie müssen über Administrator-/Lokale Systemanmeldeinformationen verfügen, um die Registrierungswerte ändern und die Protokolldateien und den Ordner, in dem sie enthalten sind, anzeigen oder ändern zu können.

Konfigurationsinformationen in den Registrierungswerten werden gelesen, wenn der HTTP-API-Treiber gestartet wird. Wenn Sie also die Einstellungen ändern, müssen Sie den Treiber beenden und dann neu starten, um die neuen Werte zu lesen. Geben Sie dazu die folgenden Konsolenbefehle ein:

net stop http
net start http

Die folgende Namenskonvention wird verwendet, um die Protokolldateien zu benennen:
httperr + Sequenznummer + .log
Beispiel: httperr4.log

Protokolldateien werden durchlaufen, wenn sie die maximale Größe erreichen, die der Registrierungswert ErrorLogFileTruncateSize angibt. Dieser Wert darf nicht kleiner als 1 Megabyte (MB) sein.

Wenn die Konfiguration der Fehlerprotokollierung ungültig ist oder eine Art von Fehler auftritt, während die HTTP-API in die Protokolldateien schreibt, verwendet die HTTP-API die Ereignisprotokollierung, um Administratoren zu benachrichtigen, dass keine Fehlerprotokollierung auftritt.

In der folgenden Tabelle werden die Registrierungskonfigurationswerte beschrieben.

Registrierungswert Beschreibung
EnableErrorLogging Ein DWORD, das Sie auf TRUE festlegen können, um die Fehlerprotokollierung zu aktivieren, oder auf FALSE, um sie zu deaktivieren. Der Standardwert ist TRUE.
ErrorLogFileTruncateSize Ein DWORD, das die maximale Größe einer Fehlerprotokolldatei in Bytes angibt. Der Standardwert ist 1 MB (0x100000).

Der angegebene Wert darf nicht kleiner als der Standardwert sein.
ErrorLoggingDir Eine Zeichenfolge, die den Ordner angibt, in dem die HTTP-API ihre Protokolldateien platziert.

Die HTTP-API erstellt einen Unterordner HTTPERR im angegebenen Ordner und speichert dann die Protokolldateien im Unterordner. Dieser Unterordner und die Protokolldateien erhalten die gleichen Berechtigungseinstellungen. Das Administrator- und das lokale Systemkonto haben Vollzugriff. Andere Benutzer haben keinen Zugriff.

Das folgende Beispiel ist der Standardordner, wenn der Ordner nicht in der Registrierung angegeben ist:
%SystemRoot%\System32\LogFiles

Der ErrorLoggingDir-Zeichenfolgenwert muss ein vollqualifizierter lokaler Pfad sein. Sie kann jedoch enthalten %SystemRoot%. Ein Netzlaufwerk oder eine Netzwerkfreigabe kann nicht verwendet werden.

Format der HTTP-API-Fehlerprotokolle

Im Allgemeinen haben HTTP-API-Fehlerprotokolldateien das gleiche Format wie W3C-Fehlerprotokolle, mit der Ausnahme, dass HTTP-API-Fehlerprotokolldateien keine Spaltenüberschriften enthalten. Jede Zeile eines HTTP-API-Fehlerprotokolls zeichnet einen Fehler auf. Die Felder werden in einer bestimmten Reihenfolge angezeigt. Ein einzelnes Leerzeichen (0x0020) trennt jedes Feld vom vorherigen Feld. In jedem Feld ersetzen Pluszeichen (0x002B) Leerzeichen, Registerkarten und nicht druckbare Steuerzeichen.

In der folgenden Tabelle werden die Felder und die Reihenfolge der Felder in einem Fehlerprotokolldatensatz angegeben.

Feld Beschreibung
Datum Das Feld Datum folgt dem W3C-Format. Dieses Feld basiert auf koordinierter Weltzeit (UTC). Das Feld Datum besteht immer aus 10 Zeichen im Format JJJJ-MM-TT. Der 1. Mai 2003 wird beispielsweise als 2003-05-01 ausgedrückt.
Time Das Feld Zeit folgt dem W3C-Format. Dieses Feld basiert auf UTC. Das Zeitfeld besteht immer aus acht Zeichen im Format MM:HH:SS. Beispielsweise wird 17:30 Uhr (UTC) als 17:30:00 ausgedrückt.
IP-Adresse (Internet Protocol) des Clients Die IP-Adresse des betroffenen Clients. Der Wert in diesem Feld kann entweder eine IPv4-Adresse oder eine IPv6-Adresse sein. Wenn es sich bei der Client-IP-Adresse um eine IPv6-Adresse handelt, ist auch das Feld ScopeId in der Adresse enthalten.
Clientport Die Portnummer für den betroffenen Client.
Server-IP-Adresse Die IP-Adresse des betroffenen Servers. Der Wert in diesem Feld kann entweder eine IPv4-Adresse oder eine IPv6-Adresse sein. Wenn es sich bei der Server-IP-Adresse um eine IPv6-Adresse handelt, ist auch das Feld ScopeId in der Adresse enthalten.
Serverport Die Portnummer des betroffenen Servers.
Protokollversion Die Version des verwendeten Protokolls.

Wenn die Verbindung nicht ausreichend analysiert wurde, um die Protokollversion zu bestimmen, wird ein Bindestrich (0x002D) als Platzhalter für das leere Feld verwendet.

Wenn entweder die Hauptversionsnummer oder die analysierte Nebenversionsnummer größer oder gleich 10 ist, wird die Version als HTTP/?.?.
Verb Das Verb gibt die letzte Anforderung an, die analysiert wird. Unbekannte Verben sind enthalten, aber jedes Verb, das mehr als 255 Bytes ist, wird auf diese Länge abgeschnitten. Wenn kein Verb verfügbar ist, wird ein Bindestrich (0x002D) als Platzhalter für das leere Feld verwendet.
CookedURL + Abfrage Die URL und alle ihr zugeordneten Abfragen werden als ein Feld protokolliert, das durch ein Fragezeichen (0x3F) getrennt ist. Dieses Feld wird bei seiner Längengrenze von 4.096 Bytes abgeschnitten.

Wenn diese URL analysiert ("gekocht") wurde, wird sie mit der lokalen Codepagekonvertierung protokolliert und als Unicode-Feld behandelt.

Wenn diese URL zum Zeitpunkt der Protokollierung nicht analysiert ("gekocht") wurde, wird sie ohne Unicode-Konvertierung genau kopiert.

Wenn die HTTP-API diese URL nicht analysieren kann, wird ein Bindestrich (0x002D) als Platzhalter für das leere Feld verwendet.
Protokollstatus Das Protokoll status darf nicht größer als 999 sein.

Wenn das Protokoll status der Antwort auf eine Anforderung verfügbar ist, wird es in diesem Feld protokolliert.

Wenn das Protokoll status nicht verfügbar ist, wird ein Bindestrich (0x002D) als Platzhalter für das leere Feld verwendet.
SiteId Wird in dieser Version der HTTP-API nicht verwendet. In diesem Feld wird immer ein Platzhalterbindestrich (0x002D) angezeigt.
Grundausdruck Dieses Feld enthält eine Zeichenfolge, die die Art des protokollierten Fehlers identifiziert. Dieses Feld wird nie leer gelassen.
Warteschlangenname Dies ist der Name der Anforderungswarteschlange.

Die folgenden Beispielzeilen stammen aus einem HTTP-API-Fehlerprotokoll:

2002-07-05 18:45:09 172.31.77.6 2094 172.31.77.6 80 HTTP/1.1 GET /qos/1kbfile.txt 503 - ConnLimit  
2002-07-05 19:51:59 127.0.0.1 2780 127.0.0.1 80 HTTP/1.1 GET /ThisIsMyUrl.htm 400 - Hostname  
2002-07-05 19:53:00 127.0.0.1 2894 127.0.0.1 80 HTTP/2.0 GET / 505 - Version_N/S  
2002-07-05 20:06:01 172.31.77.6 64388 127.0.0.1 80 - - - - - Timer_MinBytesPerSecond

Arten von Fehlern, die die HTTP-API protokolliert

Die HTTP-API protokolliert Fehlerantworten für Clients, Verbindungstimeouts, verwaiste Anforderungen und nicht ordnungsgemäß verarbeitete Verbindungen.

In der folgenden Liste sind die Arten von Fehlern aufgeführt, die von der HTTP-API protokolliert werden:

  • Antworten an Clients
    Die HTTP-API sendet eine Fehlerantwort an einen Client, z. B. einen Fehler 400, der durch einen Analysefehler in der letzten empfangenen Anforderung verursacht wird. Nachdem die HTTP-API die Fehlerantwort gesendet hat, wird die Verbindung geschlossen.

  • Verbindungstimeouts
    Bei der HTTP-API wird ein Zeitüberschreitung für eine Verbindung ausgeführt. Wenn eine Anforderung aussteht, wenn für die Verbindung ein Zeitlimit auftritt, wird die Anforderung verwendet, um weitere Informationen zur Verbindung im Fehlerprotokoll bereitzustellen.

  • Verwaiste Anforderungen
    Ein Benutzermodusprozess wird unerwartet beendet, während weiterhin Anforderungen in der Warteschlange vorhanden sind, die an diesen Prozess weitergeleitet werden. Die HTTP-API protokolliert die verwaisten Anforderungen im Fehlerprotokoll. Bestimmte Fehlertypen werden durch Reason Phrase-Zeichenfolgen benannt, die immer als letztes Feld jeder Fehlerzeile angezeigt werden. In der folgenden Tabelle sind die HTTP-API-Grundbegriffe aufgeführt.

Grundausdruck Beschreibung
AppOffline Fehler "Dienst nicht verfügbar" (HTTP-Fehler 503). Der Dienst ist nicht verfügbar, da Anwendungsfehler dazu geführt haben, dass die Anwendung offline geschaltet wurde.
AppPoolTimer Fehler "Dienst nicht verfügbar" (HTTP-Fehler 503). Der Dienst ist nicht verfügbar, da der Anwendungspoolprozess zu ausgelastet ist, um die Anforderung zu verarbeiten.
AppShutdown Fehler "Dienst nicht verfügbar" (HTTP-Fehler 503). Der Dienst ist nicht verfügbar, da die Anwendung als Reaktion auf eine Administratorrichtlinie automatisch heruntergefahren wird.
BadRequest Beim Verarbeiten einer Anforderung ist ein Analysefehler aufgetreten.
Client_Reset Die Verbindung zwischen dem Client und dem Server wurde geschlossen, bevor die Anforderung einem Arbeitsprozess zugewiesen werden konnte. Die häufigste Ursache für dieses Verhalten ist, dass der Client seine Verbindung mit dem Server vorzeitig schließt.
Connection_Abandoned_By_AppPool Ein Arbeitsprozess aus dem Anwendungspool wurde unerwartet beendet oder eine ausstehende Anforderung verwaist, indem sein Handle geschlossen wurde.
Connection_Abandoned_By_ReqQueue Ein Arbeitsprozess aus dem Anwendungspool wurde unerwartet beendet oder eine ausstehende Anforderung verwaist, indem sein Handle geschlossen wurde. Spezifisch für Windows Vista und höhere Versionen sowie für Windows Server 2008 und höhere Versionen.
Connection_Dropped Die Verbindung zwischen dem Client und dem Server wurde geschlossen, bevor der Server sein endgültiges Antwortpaket senden konnte. Die häufigste Ursache für dieses Verhalten ist, dass der Client seine Verbindung mit dem Server vorzeitig schließt.
Connection_Dropped_List_Full Die Liste der unterbrochenen Verbindungen zwischen Clients und dem Server ist voll. Spezifisch für Windows Vista und höhere Versionen sowie für Windows Server 2008 und höhere Versionen.
ConnLimit Fehler "Dienst nicht verfügbar" (HTTP-Fehler 503). Der Dienst ist nicht verfügbar, da das Verbindungslimit auf Standortebene erreicht oder überschritten wurde.
Connections_Refused Der Kernel-NonPagedPool-Arbeitsspeicher ist unter 20 MB gesunken, und http.sys hat den Empfang neuer Verbindungen beendet.
Deaktiviert Fehler "Dienst nicht verfügbar" (HTTP-Fehler 503). Der Dienst ist nicht verfügbar, da ein Administrator die Anwendung offline geschaltet hat.
EntityTooLarge Eine Entität hat die maximal zulässige Größe überschritten.
FieldLength Ein Feldlängenlimit wurde überschritten.
Verboten (Forbidden) Ein verbotenes Element oder eine verbotene Sequenz wurde beim Analysieren erfüllt.
Kopfzeile In einem Header ist ein Analysefehler aufgetreten.
Hostname Beim Verarbeiten eines Hostnamens ist ein Analysefehler aufgetreten.
Intern Interner Serverfehler (HTTP-Fehler 500).
Invalid_CR/LF Ein ungültiger Wagenrücklauf oder Zeilenvorschub ist aufgetreten.
LengthRequired Ein erforderlicher Längenwert fehlt.
Nicht zutreffend Fehler "Dienst nicht verfügbar" (HTTP-Fehler 503). Der Dienst ist nicht verfügbar, da ein interner Fehler (z. B. speicherbelegungsfehler oder URL-Reservierungslistenkonflikt) aufgetreten ist.
N/I Aufgrund einer unbekannten Übertragungscodierung ist ein nicht implementierter Fehler aufgetreten (HTTP-Fehler 501), oder ein Dienstfehler ist nicht verfügbar (HTTP-Fehler 503).
Zahl Beim Verarbeiten einer Zahl ist ein Analysefehler aufgetreten.
Voraussetzung Eine erforderliche Voraussetzung fehlte.
QueueFull Fehler "Dienst nicht verfügbar" (HTTP-Fehler 503). Der Dienst ist nicht verfügbar, da die Anwendungsanforderungswarteschlange voll ist.
RequestLength Ein Grenzwert für die Anforderungslänge wurde überschritten.
Timer_AppPool Die Verbindung ist abgelaufen, weil eine Anforderung in einer Anwendungspoolwarteschlange zu lange gewartet hat, bis eine Serveranwendung die Warteschlange aufheben und verarbeiten kann. Diese Timeoutdauer ist ConnectionTimeout. Standardmäßig ist dieser Wert auf zwei Minuten festgelegt.
Timer_ConnectionIdle Die Verbindung ist abgelaufen und verbleibt im Leerlauf. Die Standardmäßige ConnectionTimeout-Dauer beträgt zwei Minuten.
Timer_EntityBody Die Verbindung ist abgelaufen, bevor der Anforderungsentitätstext eingetroffen ist. Wenn eine Anforderung eindeutig über einen Entitätstext verfügt, aktiviert die HTTP-API den Timer_EntityBody Timer. Zunächst wird der Grenzwert dieses Timers auf den ConnectionTimeout-Wert (in der Regel zwei Minuten) festgelegt. Jedes Mal, wenn eine weitere Datenanzeige für diese Anforderung empfangen wird, setzt die HTTP-API den Timer zurück, um der Verbindung zwei weitere Minuten (oder was in ConnectionTimeout angegeben ist) zu geben.
Timer_HeaderWait Die Verbindung ist abgelaufen, da die Analyse des Headers für eine Anforderung länger dauerte als das Standardlimit von zwei Minuten.
Timer_MinBytesPerSecond Die Verbindung ist abgelaufen, weil der Client keine Antwort mit angemessener Geschwindigkeit empfangen hat. Die Antwortsenderate war langsamer als der Standardwert von 240 Bytes/s. Dies kann mit der MinFileBytesPerSec-Metabasiseigenschaft gesteuert werden.
Timer_ReqQueue Die Verbindung ist abgelaufen, weil eine Anforderung in einer Anwendungspoolwarteschlange zu lange gewartet hat, bis eine Serveranwendung die Warteschlange aufhebt. Diese Timeoutdauer ist ConnectionTimeout. Standardmäßig ist dieser Wert auf zwei Minuten festgelegt. Spezifisch für Windows Vista und höhere Versionen sowie für Windows Server 2008 und höhere Versionen.
Timer_Response Reserviert. Derzeit nicht verwendet.
Timer_SslRenegotiation
 Die Verbindung ist abgelaufen, weil die SSL-Neuverhandlung (Secure Sockets Layer) zwischen Client und Server länger dauerte als das Standardtimeout von zwei Minuten.
URL Beim Verarbeiten einer URL ist ein Analysefehler aufgetreten.
URL_Length Eine URL hat die maximal zulässige Größe überschritten.
Verb Beim Verarbeiten eines Verbs ist ein Analysefehler aufgetreten.
Version_N/S Es ist ein Fehler aufgetreten, der von der Version nicht unterstützt wird (HTTP-Fehler 505).