Freigeben über

Problembehandlung bei HTTP 400-Fehlern in IIS

  • Artikel

Gilt für: Internetinformationsdienste

In diesem Artikel werden die Schritte zur Problembehandlung beschrieben, um die Ursache verschiedener HTTP 400-Fehler bei verwendung von IIS zu identifizieren.

Übersicht

Nachdem ein HTTP-Client (z. B. Microsoft Edge) eine HTTP-Anforderung an einen IIS-Server sendet, wird möglicherweise der folgende Fehlermeldungstyp angezeigt:

HTTP 400 – Ungültige Anforderung

In diesem Szenario lehnt IIS die HTTP-Anforderung des Clients ab, da die Anforderung die HTTP-Analyseregeln des Servers nicht erfüllt, die Zeitlimits überschreitet oder einige andere Regeln fehlschlägt, die IIS oder HTTP.sys erfordert, dass eingehende Anforderungen eingehalten werden. IIS sendet den HTTP 400 - Bad Request Status zurück an den Client und beendet dann die TCP-Verbindung.

Extras

Methoden zur Problembehandlung

Bei der Problembehandlung bei einer HTTP 400-Bedingung ist es wichtig zu beachten, dass das zugrunde liegende Problem darin besteht, dass der Client eine Anforderung an IIS gesendet hat, die eine oder mehrere Regeln unterbricht, die HTTP.sys erzwingen. In diesem Zusammenhang möchten Sie sehen, was genau der Client an IIS sendet. Erfassen Sie dazu eine Netzwerkablaufverfolgung des Clients, der die ungültige Anforderung sendet. Sie können die Ablaufverfolgung analysieren, um die Rohdaten anzuzeigen, die der Client an IIS sendet, und um die rohen Antwortdaten anzuzeigen, die IIS an den Client zurücksendet. Sie können auch ein HTTP-Sniffer-Tool namens Fiddler verwenden, ein großartiges Tool, da es Ihnen ermöglicht, die HTTP-Header anzuzeigen, auch wenn der Client und der Server über SSL kommunizieren.

Das nächste verwendete Datenelement ist die Datei "C:\Windows\System32\LogFiles\HTTPERR\httperr.log ". In IIS verarbeitet die HTTP.sys komponente eingehende HTTP-Anforderungen, bevor sie an IIS übergeben werden, und ist für das Blockieren von Anforderungen verantwortlich, die die IIS-Anforderungen nicht erfüllen. Wenn HTTP.sys die Anforderung blockiert, protokolliert sie Informationen zu ihrer httperr.log Datei bezüglich der fehlerhaften Anforderung und warum sie blockiert wurde.

Notiz

Weitere Informationen zur HTTP-API-Fehlerprotokollierung, die HTTP.sys bereitstellt, finden Sie unter Fehlerprotokollierung in der HTTP-API.

Es ist technisch möglich, obwohl nicht sehr wahrscheinlich, dass ein Client eine HTTP 400-Antwort empfängt, die keinen zugeordneten Protokolleintrag in der httperr.log-Datei enthält. Dies kann passieren, wenn ein ISAPI-Filter oder eine Erweiterung oder ein HTTP-Modul in IIS den Status 400 festlegt. In diesem Fall könnten Sie sich das IIS-Protokoll ansehen, um weitere Informationen zu erfahren. Es kann auch passieren, wenn eine Entität zwischen dem Client und dem Server, z. B. einem Proxyserver oder einem anderen Netzwerkgerät, eine Antwort von IIS abfangen und ihn mit seinem eigenen 400-Status und/oder "Ungültige Anforderung" überschreibt.

Notiz

In diesem Artikel werden hauptsächlich die allgemeinen HTTP 400-Fehler erläutert, bevor Sie Ihre Website erreichen. In einigen Szenarien gibt Ihre Website möglicherweise auch HTTP 400-Fehler aufgrund von benutzerdefinierter Codelogik oder Laufzeitkonfiguration (z. B. ASP.NET) an Clients zurück. Wenn Sie die HTTP 400-Fehler nach dem Ausführen der Schritte in den folgenden Abschnitten immer noch nicht beheben können, versuchen Sie, die Problembehandlung mithilfe des Features "Fehlgeschlagene Anforderungsablaufverfolgung" in IIS zu beheben. Wenn Sie feststellen, dass die HTTP 400-Fehler tatsächlich vom entsprechenden Laufzeithandler Ihrer Website festgelegt werden, z. B. ASP.NET, müssen Sie möglicherweise die Details der Anforderungen und Antworten zusammen mit der zugehörigen Codelogik und Laufzeitkonfiguration Ihrer Website überprüfen, um die Ursache der HTTP 400-Fehler zu verstehen.

Beispielszenario

Nachfolgend sehen Sie ein Beispiel für ein HTTP 400-Szenario, in dem ein Client eine ungültige Anforderung an IIS sendet und der Server eine "HTTP 400 - Ungültige Anforderung" zurücksendet.

Wenn der Client seine Anforderung sendet, sieht der Browserfehler wie folgt aus:

Ungültige Anforderung (Kopfzeilenfeld zu lang)

Wenn Sie eine Netzwerkablaufverfolgung der Anforderung und Antwort erfassen, werden die folgenden Ausgaben angezeigt:

BITTEN:

HTTP: GET Request from Client
HTTP: Request Method =GET
HTTP: Uniform Resource Identifier =/1234567890123456789012345678901234567890/time.asp
HTTP: Protocol Version =HTTP/1.1
HTTP: Accept-Language =en-us
HTTP: UA-cpu =x86
HTTP: Accept-Encoding =gzip, deflate
HTTP: Host =iisserver
HTTP: Connection =Keep-Alive
HTTP: Data: Number of data bytes remaining = 14 (0x000E)

ANTWORT:

HTTP: Response to Client; HTTP/1.1; Status Code = 400 - Bad Request
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = Bad Request
HTTP: Reason =Bad Request
HTTP: Content-Type =text/html
HTTP: Date =Wed, 14 Nov 2012 20:36:36 GMT
HTTP: Connection =close
HTTP: Content-Length =44
HTTP: Data: Number of data bytes remaining = 63 (0x003F)

Sie stellen fest, dass die Antwortheader nicht so viel sagen wie die Fehlermeldung im Browser. Wenn Sie jedoch die Rohdaten im Antworttext betrachten, sehen Sie mehr:

00000030                                           48 54               HT
00000040 54 50 2F 31 2E 31 20 34 30 30 20 42 61 64 20 52 TP/1.1.400.Bad.R
00000050 65 71 75 65 73 74 0D 0A 43 6F 6E 74 65 6E 74 2D equest..Content-
00000060 54 79 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C 0D Type:.text/html.
00000070 0A 44 61 74 65 3A 20 57 65 64 2C 20 32 38 20 4A .Date:.Wed,.28.J
00000080 61 6E 20 32 30 30 39 20 32 30 3A 33 36 3A 33 36 an.2009.20:36:36
00000090 20 47 4D 54 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E .GMT..Connection
000000A0 3A 20 63 6C 6F 73 65 0D 0A 43 6F 6E 74 65 6E 74 :.close..Content
000000B0 2D 4C 65 6E 67 74 68 3A 20 34 34 0D 0A 0D 0A 3C -Length:.44....<
000000C0 68 31 3E 42 61 64 20 52 65 71 75 65 73 74 20 28 h1>Bad.Request.(
000000D0 48 65 61 64 65 72 20 46 69 65 6C 64 20 54 6F 6F Header.Field.Too
000000E0 20 4C 6F 6E 67 29 3C 2F 68 31 3E 01 02 03 04 05 .Long).....
000000F0 05 06 0E 94 63 D6 68 37 1B 8C 16 FE 3F D5       ....c.h7....?.

Sie können sehen, dass der im Browser angezeigte Fehlermeldungstext auch in den rohen Antwortdaten in der Netzwerkablaufverfolgung angezeigt werden kann.

Der nächste Schritt besteht darin, die httperr.log Datei im Verzeichnis "C:\Windows\System32\LogFiles\HTTPERR" nach dem Eintrag zu betrachten, der der ungültigen Anforderung entspricht:

#Software: Microsoft HTTP API 1.0
#Version: 1.0
#Date: 2012-11-14 20:35:02
#Fields: date time cs-version cs-method cs-uri sc-status s-reason 
2012-11-14 20:36:36 HTTP/1.1 GET /1234567890/time.asp 400 FieldLength

In diesem Szenario enthält das Reason Feld in der datei httperr.log die genauen Informationen, die Sie zum Diagnostizieren des Problems benötigen. Sie sehen, dass HTTP.sys als Grund für den Fehler dieser Anforderung protokolliert FieldLength wurden. Nachdem Sie den Grundausdruck kennen, überprüfen Sie die Tabelle in "Arten von Fehlern", die der Abschnitt "HTTP-API-Protokolle" enthält , um die Beschreibung zu erhalten:

FieldLength: Es wurde ein Grenzwert für die Feldlänge überschritten.

An diesem Punkt wissen Sie also aus der Browserfehlermeldung und der HTTP-API-Fehlerprotokollierung, dass die Anforderung Daten in einem seiner HTTP-Header enthielt, die die zulässigen Längenbeschränkungen überschritten haben. In diesem Beispiel ist dies HTTP: Uniform Resource Identifier header absichtlich lang: /1234567890123456789012345678901234567890/time.asp.

Die letzte Phase der Problembehandlung in diesem Beispiel besteht darin, die HTTP.sys Registrierungsschlüssel und Standardeinstellungen für IIS zu überprüfen .

Da Sie wissen, warum der Ausdruck und fehler ein Kopfzeilenfeld überschreiten, das Grenzwerte überschreitet, können Sie unsere Suche in der Tabelle "Registrierungsschlüssel " einschränken. Der wichtigste Kandidat hier ist:

Registrierungsschlüssel Standardwert Gültiger Wertbereich Registrierungsschlüsselfunktion WARNUNGscode
MaxFieldLength 16384 64 - 65534 (64k - 2) Bytes Legt einen oberen Grenzwert für jede Kopfzeile fest. Siehe MaxRequestBytes. Dieser Grenzwert wird für eine URL auf ungefähr 32k Zeichen übersetzt. 1

Um diesen Fehler für dieses Beispiel zu reproduzieren, wurde der MaxFieldLength Registrierungsschlüssel mit dem Wert 2 festgelegt. Da die angeforderte URL über ein HTTP: Uniform Resource Identifier header Feld mit mehr als zwei Zeichen verfügte, wurde die Anforderung mit dem FieldLength Grundausdruck blockiert.

Ein weiteres gängiges HTTP 400-Szenario ist ein Szenario, bei dem der Benutzer, der die HTTP-Anforderung vornimmt, mitglied einer großen Anzahl von Active Directory-Gruppen ist und die Website für die Kerberos-Authentifizierung des Benutzers konfiguriert ist. Wenn dieses Szenario auftritt, wird dem Benutzer eine Fehlermeldung ähnlich der folgenden angezeigt:

Ungültige Anforderung (Anforderungsheader zu lang)

In diesem Szenario ist das Authentifizierungstoken, das als Teil der HTTP-Anforderung des Clients enthalten ist, zu groß und überschreitet Größenbeschränkungen, die http.sys erzwingen. Dieses Problem wird in HTTP 400 - Ungültige Anforderungsantworten (Anforderungsheader zu lang) ausführlich zusammen mit der Lösung behandelt.

References