Fehlerprotokollierung in HTTP-APIs

  • Artikel
  • 9 Minuten Lesedauer

In diesem Artikel werden die Fehlerprotokollierungsfunktionen von HTTP-Anwendungsprogrammierschnittstellen (APPLICATION Programming Interfaces, APIs) von 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 übergeben zu werden. Dieses Verhalten tritt auf, da die Häufigkeit solcher Fehler andernfalls ein Ereignisprotokoll oder einen Anwendungshandler überschwemmen könnte.

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 beenden und dann den Treiber 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 + 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 MB sein.

Wenn die Konfiguration der Fehlerprotokollierung nicht gültig ist oder wenn während des Schreibens der HTTP-API in die Protokolldateien ein Fehler auftritt, verwendet die HTTP-API die Ereignisprotokollierung, um Administratoren zu benachrichtigen, dass die Fehlerprotokollierung nicht 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-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 Administratorkonten 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. Es kann jedoch enthalten %SystemRoot%sein. Ein Netzlaufwerk oder eine Netzwerkfreigabe kann nicht verwendet werden.

Format der HTTP-API-Fehlerprotokolle

Im Allgemeinen haben HTTP-API-Fehlerprotokolldateien dasselbe 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 Fehlerprotokolleintrag angegeben.

Feld Beschreibung
Datum Das Feld Date folgt dem W3C-Format. Dieses Feld basiert auf koordinierter Weltzeit (COORDINATED Universal Time, UTC). Das Datumsfeld ist immer 10 Zeichen in Form von JJJJ-MM-TT. Beispielsweise wird der 1. Mai 2003 als 2003-05-01 ausgedrückt.
Zeit Das Feld Zeit folgt dem W3C-Format. Dieses Feld basiert auf UTC. Das Zeitfeld weist immer acht Zeichen in Form von MM:HH:SS auf. Beispiel: 17:30 Uhr (UTC) wird als 17:30:00 Uhr 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 es sich bei der Client-IP-Adresse um eine IPv6-Adresse handelt, ist auch das ScopeId-Feld 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 Ip-Adresse des Servers 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 ermitteln, wird ein Bindestrich (0x002D) als Platzhalter für das leere Feld verwendet.

Wenn die Hauptversionsnummer oder die Nebenversionsnummer, die analysiert wird, 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 mit mehr als 255 Byte 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 + Query Die URL und alle ihr zugeordneten Abfragen werden als ein Feld protokolliert, das durch ein Fragezeichen (0x3F) getrennt ist. Dieses Feld wird bei seinem Längenlimit von 4.096 Byte abgeschnitten.

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

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

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 Platzhalterhyphen (0x002D) angezeigt.
Reason-Ausdruck Dieses Feld enthält eine Zeichenfolge, die die Art des protokollierten Fehlers identifiziert. Dieses Feld ist nie leer.
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 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
    Die HTTP-API führt zu einem Zeitüberschreitung einer Verbindung. Wenn eine Anforderung aussteht, wenn das Verbindungstimeout auftritt, wird die Anforderung verwendet, um weitere Informationen zur Verbindung im Fehlerprotokoll bereitzustellen.

  • Verwaiste Anforderungen
    Ein Benutzermodusprozess wird unerwartet beendet, während noch Anforderungen in die Warteschlange eingereiht sind, die an diesen Prozess weitergeleitet werden. Die HTTP-API protokolliert die verwaisten Anforderungen im Fehlerprotokoll. Bestimmte Fehlertypen werden nach Zeichenfolgen des Reason-Ausdrucks benannt, die immer als letztes Feld jeder Fehlerzeile angezeigt werden. In der folgenden Tabelle sind die GRÜNDE FÜR DIE HTTP-API aufgeführt.

Reason-Ausdruck 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öher.
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 verworfenen 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öher.
ConnLimit Fehler "Dienst 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 wurde unter 20 MB entfernt, und http.sys keine neuen Verbindungen mehr empfängt
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 Grenzwert für die Feldlänge wurde überschritten.
Verboten (Forbidden) Während der Analyse wurde ein unzulässiges Element oder eine unzulässige Sequenz erreicht.
Kopfzeile In einem Header ist ein Analysefehler aufgetreten.
Hostname Beim Verarbeiten eines Hostnamens ist ein Analysefehler aufgetreten.
Intern Ein interner Serverfehler (HTTP-Fehler 500) ist aufgetreten.
Invalid_CR/LF Ein unzulässiger Wagenrücklauf oder Zeilenvorschub ist aufgetreten.
LengthRequired Ein erforderlicher Längenwert fehlte.
Nicht zutreffend Fehler "Dienst nicht verfügbar" (HTTP-Fehler 503). Der Dienst ist nicht verfügbar, da ein interner Fehler (z. B. ein Speicherzuweisungsfehler oder ein Konflikt mit der URL-Reservierungsliste) aufgetreten ist.
N/I Aufgrund einer unbekannten Übertragungscodierung ist ein nicht implementierter Fehler aufgetreten (HTTP-Fehler 501), oder es ist ein Dienstfehler (HTTP-Fehler 503) aufgetreten.
Zahl Beim Verarbeiten einer Zahl ist ein Analysefehler aufgetreten.
Voraussetzung Eine erforderliche Vorbedingung 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, da eine Anforderung in einer Anwendungspoolwarteschlange zu lange gewartet hat, damit eine Serveranwendung die Warteschlange aufstellt und verarbeitet. Diese Timeoutdauer ist ConnectionTimeout. Standardmäßig ist dieser Wert auf zwei Minuten festgelegt.
Timer_ConnectionIdle Die Verbindung ist abgelaufen und bleibt im Leerlauf. Die Standarddauer von ConnectionTimeout beträgt zwei Minuten.
Timer_EntityBody Die Verbindung ist abgelaufen, bevor der Anforderungsentitätstext eingetroffen ist. Wenn eine Anforderung eindeutig einen Entitätstext aufweist, aktiviert die HTTP-API den Timer_EntityBody-Timer. Zunächst wird das Limit dieses Timers auf den ConnectionTimeout-Wert festgelegt (in der Regel zwei Minuten). Jedes Mal, wenn eine andere Datenanzeige bei dieser 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 Header-Analyse für eine Anforderung länger als das Standardlimit von zwei Minuten gedauert hat.
Timer_MinBytesPerSecond Die Verbindung ist abgelaufen, da der Client keine Antwort mit einer angemessenen Geschwindigkeit empfangen hat. Die Antwortsenderrate war langsamer als der Standardwert 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, damit eine Serveranwendung die Warteschlange aufstellt. 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öher.
Timer_Response Reserviert. Wird derzeit nicht verwendet.
Timer_SslRenegotiation
 Die Verbindung ist abgelaufen, da die SSL-Neuverhandlung (Secure Sockets Layer) zwischen Client und Server länger als das Standardtimeout von zwei Minuten dauerte.
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 Ein nicht unterstützter Fehler ist aufgetreten (HTTP-Fehler 505).