Fehlerprotokollierung in HTTP-APIs
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.
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 Standardtools verwenden, um diese Protokolldateien zu analysieren. Im Gegensatz zu W3C-Protokolldateien enthalten HTTP-API-Protokolldateien jedoch nicht die Spaltennamen.Arten von Fehlern, die die HTTP-API protokolliert
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 ä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). |
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unterFeedback senden und anzeigen für