Fehlerprotokollierung in HTTP-APIs

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

Originalversion des Produkts: 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 zurück an eine Anwendung übergeben zu werden. Dieses Verhalten tritt auf, weil die Häufigkeit solcher Fehler andernfalls ein Ereignisprotokoll oder einen Anwendungshandler überfluten kann.

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 zu ändern und die Protokolldateien und den Ordner, in dem sie enthalten sind, anzuzeigen oder zu ändern.

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 Benennungskonvention wird verwendet, um die Protokolldateien zu benennen:
httperr + sequenz number + .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 MB sein.

Wenn die Konfiguration der Fehlerprotokollierung ungültig ist oder ein 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 es zu deaktivieren. Der Standardwert ist TRUE.
ErrorLogFileTruncateSize Ein DWORD-Wert, der die maximale Größe einer Fehlerprotokolldatei in Byte 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 Protokollierungsdateien 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. Die Administrator- und lokalen Systemkonten 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 weisen HTTP-API-Fehlerprotokolldateien dasselbe Format wie W3C-Fehlerprotokolle auf, 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 identifiziert.

Feld Beschreibung
Datum Das Feld "Date" folgt dem W3C-Format. Dieses Feld basiert auf koordinierter Weltzeit (COORDINATED Universal Time, UTC). Das Feld "Datum" ist immer 10 Zeichen in Form von JJJJ-MM-TT. Beispielsweise wird der 1. Mai 2003 als 01.05.2003 ausgedrückt.
Zeit Das Feld "Zeit" folgt dem W3C-Format. Dieses Feld basiert auf UTC. Das Zeitfeld beträgt immer acht Zeichen in Form von MM:HH:SS. Beispielsweise wird 17:30:30 UHR (UTC) als 17:30:00 ausgedrückt.
IP-Adresse (Client Internet Protocol) Die IP-Adresse des betroffenen Clients. Der Wert in diesem Feld kann entweder eine IPv4-Adresse oder eine IPv6-Adresse sein. Wenn die Client-IP-Adresse eine IPv6-Adresse ist, 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 die IP-Adresse des Servers eine IPv6-Adresse ist, 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 ermitteln, wird ein Bindestrich (0x002D) als Platzhalter für das leere Feld verwendet.

Wenn die Hauptversionsnummer oder die analysierte Nebenversionsnummer größer oder gleich 10 ist, wird die Version als HTTP/?.?.
Verb Das Verb gibt an, dass die letzte analysierte Anforderung übergeben wird. Unbekannte Verben sind enthalten, aber jedes Verb, das mehr als 255 Bytes beträgt, 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 zugehörigen 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 Konvertierung der lokalen Codepage 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 Der Protokollstatus darf nicht größer als 999 sein.

Wenn der Protokollstatus der Antwort auf eine Anforderung verfügbar ist, wird er in diesem Feld protokolliert.

Wenn der Protokollstatus 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.
Reason Phrase Dieses Feld enthält eine Zeichenfolge, die die Art des protokollierten Fehlers identifiziert. Dieses Feld bleibt nie leer.
Warteschlangenname Es 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 von der HTTP-API protokolliert werden

Die HTTP-API protokolliert Fehlerantworten auf Clients, Verbindungstimeouts, verwaiste Anforderungen und verworfene Verbindungen, die falsch behandelt werden.

In der folgenden Liste werden die Arten von Fehlern identifiziert, die von der HTTP-API protokolliert werden:

  • Antworten auf Clients
    Die HTTP-API sendet eine Fehlerantwort an einen Client, z. B. einen 400-Fehler, 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 eine Verbindung unterbrochen. Wenn beim Verbindungsausfall eine Anforderung aussteht, wird die Anforderung verwendet, um weitere Informationen zur Verbindung im Fehlerprotokoll bereitzustellen.

  • Verwaiste Anforderungen
    Ein Benutzermodusprozess wird unerwartet beendet, während noch 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 Zeichenfolgen des Grundausdrucks benannt, die immer als letztes Feld jeder Fehlerzeile angezeigt werden. In der folgenden Tabelle sind die HTTP-API-Grundausdrücke aufgeführt.

Reason Phrase Beschreibung
AppOffline Ein Dienstfehler ist nicht verfügbar (HTTP-Fehler 503). Der Dienst ist nicht verfügbar, weil Anwendungsfehler dazu geführt haben, dass die Anwendung offline geschaltet wurde.
AppPoolTimer Ein Dienstfehler ist nicht verfügbar (HTTP-Fehler 503). Der Dienst ist nicht verfügbar, da der Anwendungspoolprozess zu ausgelastet ist, um die Anforderung zu verarbeiten.
AppShutdown Ein Dienstfehler ist nicht verfügbar (HTTP-Fehler 503). Der Dienst ist nicht verfügbar, da die Anwendung als Reaktion auf die 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 durch Schließen des Handles verwaist.
Connection_Abandoned_By_ReqQueue Ein Arbeitsprozess aus dem Anwendungspool wurde unerwartet beendet oder eine ausstehende Anforderung durch Schließen des Handles verwaist. 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 letztes 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 verworfenen Verbindungen zwischen Clients und dem Server ist vollständig. Spezifisch für Windows Vista und höhere Versionen sowie für Windows Server 2008 und höhere Versionen.
ConnLimit Ein Dienstfehler ist nicht verfügbar (HTTP-Fehler 503). Der Dienst ist nicht verfügbar, da der Verbindungsgrenzwert auf Standortebene erreicht oder überschritten wurde.
Connections_Refused Der Kernel-NonPagedPool-Speicher ist unter 20 MB gefallen, und http.sys keine neuen Verbindungen mehr erhalten hat
Deaktiviert Ein Dienstfehler ist nicht verfügbar (HTTP-Fehler 503). Der Dienst ist nicht verfügbar, weil 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) Während der Analyse wurde ein unzulässiges Element oder eine unzulässige Sequenz gefunden.
Header In einer Kopfzeile ist ein Analysefehler aufgetreten.
Hostname Beim Verarbeiten eines Hostnamens ist ein Analysefehler aufgetreten.
Intern Interner Serverfehler (HTTP-Fehler 500).
Invalid_CR/LF Ein illegaler Wagenrücklauf oder Zeilenvorschub ist aufgetreten.
LengthRequired Ein erforderlicher Längenwert fehlte.
Nicht zutreffend Ein Dienstfehler ist nicht verfügbar (HTTP-Fehler 503). Der Dienst ist nicht verfügbar, weil ein interner Fehler (z. B. ein Speicherzuweisungsfehler oder ein URL-Reservierungslistenkonflikt) aufgetreten ist.
N/I Es ist ein nicht implementierter Fehler (HTTP-Fehler 501) oder ein Dienstfehler nicht verfügbar (HTTP-Fehler 503) aufgrund einer unbekannten Übertragungscodierung aufgetreten.
Zahl Beim Verarbeiten einer Zahl ist ein Analysefehler aufgetreten.
Voraussetzung Eine erforderliche Voraussetzung fehlte.
QueueFull Ein Dienstfehler ist 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 aufgehoben und verarbeitet hat. Diese Timeoutdauer ist ConnectionTimeout. Standardmäßig ist dieser Wert auf zwei Minuten festgelegt.
Timer_ConnectionIdle Die Verbindung ist abgelaufen und bleibt im Leerlauf. Die Standardmäßige ConnectionTimeout-Dauer beträgt zwei Minuten.
Timer_EntityBody Die Verbindung ist abgelaufen, bevor der Anforderungsentitätstext eingegangen 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 festgelegt (in der Regel zwei Minuten). Jedes Mal, wenn eine andere Datenanzeige für diese Anforderung empfangen wird, setzt die HTTP-API den Timer zurück, um der Verbindung zwei weitere Minuten zu geben (oder was auch immer in ConnectionTimeout angegeben ist).
Timer_HeaderWait Die Verbindung ist abgelaufen, da die Header-Analyse für eine Anforderung mehr Zeit in Anspruch nahm als der Standardgrenzwert von zwei Minuten.
Timer_MinBytesPerSecond Die Verbindung ist abgelaufen, weil der Client keine Antwort mit einer angemessenen Geschwindigkeit empfangen hat. Die Antwort-Senderate war langsamer als die Standardeinstellung von 240 Bytes/s. Dies kann mit der MinFileBytesPerSec-Metabasiseigenschaft gesteuert werden.
Timer_ReqQueue Die Verbindung ist abgelaufen, da eine Anforderung in einer Anwendungspoolwarteschlange zu lange gewartet hat, bis die Warteschlange für eine Serveranwendung aufgehoben wurde. 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, da die Erneutverhandlung von Secure Sockets Layer (SSL) 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 nicht unterstützt wird (HTTP-Fehler 505).