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.
Konfigurieren der HTTP-API-Fehlerprotokollierung
Registrierungseinstellungen steuern die HTTP-API-Protokollfehler, die maximal zulässige Größe von Protokolldateien und den Speicherort der Protokolldateien.Format der HTTP-API-Fehlerprotokolle
Die HTTP-API erstellt Protokolldateien, die den W3C-Protokolldateikonventionen (World Wide Web Consortium) entsprechen. Sie können diese Protokolldateien mithilfe von Standardtools analysieren. Im Gegensatz zu W3C-Protokolldateien enthalten HTTP-API-Protokolldateien jedoch nicht die Spaltennamen.Arten von Fehlern, die von der HTTP-API protokolliert werden
Die HTTP-API protokolliert viele häufige Fehler.
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). |
Feedback
https://aka.ms/ContentUserFeedback.
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see:Feedback senden und anzeigen für