Behandeln von HTTP 400-Fehlern in IIS
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
Nach dem Senden einer HTTP-Anforderung an einen IIS-Server zeigt ein HTTP-Client (z. B. Internet Explorer) möglicherweise den folgenden Typ von Fehlermeldung an:
HTTP 400Die Webseite wurde nicht gefunden.
Die wahrscheinlichsten Ursachen:
- Möglicherweise liegt ein Eingabefehler in der Adresse vor.
- Wenn Sie auf einen Link geklickt haben, ist dieser möglicherweise veraltet.
Was Sie ausprobieren können:
- Geben Sie die Adresse erneut ein.
- Zurück zur vorherigen Seite.
- Wechseln Sie zu Bing, und suchen Sie nach den gewünschten Informationen.
Wenn der HTTP-Client Internet Explorer ist und die Option Benutzerfreundliche HTTP-Fehlermeldungen anzeigen deaktiviert ist, kann der Fehler wie folgt aussehen:
Ungültige Anforderung (Bad Request)
In diesen Szenarien hat IIS die HTTP-Anforderung des Clients abgelehnt, weil die Anforderung nicht den HTTP-Analyseregeln des Servers entspricht, zeitlimits überschritten hat oder eine andere Regel fehlgeschlagen ist, deren Einhaltung von eingehenden Anforderungen von IIS oder HTTP.sys erforderlich ist. IIS sendet die status "HTTP 400 – Ungültige Anforderung" zurück an den Client und beendet dann die TCP-Verbindung.
Tools
- Netzwerkmonitor
- HTTP-Fehlerprotokollierung
Problembehandlungsmethoden
Beachten Sie bei der Problembehandlung einer HTTP 400-Bedingung, 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. Vor diesem Hintergrund 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 unformatierten 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 auch dann anzuzeigen, wenn Client und Server über SSL kommunizieren.
Das nächste Datenelement, das Sie verwenden, ist die Datei C:\Windows\System32\LogFiles\HTTPERR\httperr.log . Ab IIS 6.0 verarbeitet die komponente HTTP.sys eingehende HTTP-Anforderungen, bevor sie an IIS übergeben werden, und ist die Komponente, die für das Blockieren von Anforderungen verantwortlich ist, die die IIS-Anforderungen nicht erfüllen. Wenn HTTP.sys die Anforderung blockiert, protokolliert sie Informationen zur fehlerhaften Anforderung und zum Grund für die Sperrung in der httperr.log-Datei.
HINWEIS: Weitere Informationen zur HTTP-API-Fehlerprotokollierung, die HTTP.sys bereitstellt, finden Sie unter Fehlerprotokollierung in der HTTP-API.
Es ist technisch möglich, wenn auch nicht sehr wahrscheinlich, dass ein Client eine HTTP 400-Antwort erhält, der kein Protokolleintrag im httperr.log zugeordnet ist. Dies kann vorkommen, wenn ein ISAPI-Filter oder eine ISAPI-Erweiterung oder ein HTTP-Modul in IIS die 400 status festlegt. In diesem Fall können Sie im IIS-Protokoll nach weiteren Informationen suchen. Dies kann auch vorkommen, wenn eine Entität zwischen dem Client und dem Server, z. B. ein Proxyserver oder ein anderes Netzwerkgerät, eine Antwort von IIS abfängt und sie mit einem eigenen Fehler vom Typ 400 status und/oder "Ungültige Anforderung" überschreibt.
Beispielszenario
Es folgt ein Beispiel für ein HTTP 400-Szenario, bei dem ein Client eine ungültige Anforderung an IIS und der Server die Nachricht "HTTP 400 – Ungültige Anforderung" zurücksendet.
Wenn der Client seine Anforderung sendet, sieht der Browserfehler wie folgt aus:
Ungültige Anforderung (Headerfeld zu lang)
Beim Erfassen einer Netzwerkablaufverfolgung der Anforderung und Antwort werden die folgenden Ausgaben angezeigt:
ANFRAGE:
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 sich jedoch die Rohdaten im Antworttext ansehen, 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 suchen, 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 genau die Informationen, die Sie zum Diagnostizieren des Problems benötigen. Sie sehen, dass HTTP.sys als Ursache für den Fehler dieser Anforderung protokolliert FieldLength . Wenn Sie den Grundausdruck kennen, überprüfen Sie die Tabelle im Abschnitt Arten von Fehlern, die im Abschnitt HTTP-API protokolliert werden, um die Beschreibung zu erhalten:
FieldLength: Ein Feldlängenlimit wurde überschritten.
An diesem Punkt wissen Sie also aus der Browserfehlermeldung und der HTTP-API-Fehlerprotokollierung, dass die Anforderung Daten in einem ihrer HTTP-Header enthielt, die die zulässigen Längenbeschränkungen überschritten haben. In diesem Beispiel ist die 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 Ausdruck und Fehler eine Kopfzeilenfeldlänge überschreitet, können Sie unsere Suche in der Tabelle Registrierungsschlüssel als solche einschränken. Der Hauptkandidat ist hier:
| Registrierungsschlüssel | Standardwert | Gültiger Wertbereich | Registrierungsschlüsselfunktion | WARNUNGScode |
|---|---|---|---|---|
MaxFieldLength |
16384 | 64 bis 65534 (64.000 bis 2) Bytes | Legt eine Obergrenze für jeden Header fest. Weitere Informationen finden Sie unter MaxRequestBytes. Dieser Grenzwert entspricht ungefähr 32.000 Zeichen für eine URL. |
1 |
Um diesen Fehler für dieses Beispiel zu reproduzieren, wurde der MaxFieldLength Registrierungsschlüssel mit dem Wert 2 festgelegt. Da die angeforderte URL ein HTTP: Uniform Resource Identifier header Feld mit mehr als zwei Zeichen enthielt, wurde die Anforderung mit dem FieldLength Grundausdruck blockiert.
Ein weiteres gängiges HTTP 400-Szenario ist ein Szenario, in dem der Benutzer, der die HTTP-Anforderung stellt, Mitglied einer großen Anzahl von Active Directory-Gruppen ist und die Website für die Kerberos-Authentifizierung konfiguriert ist. In diesem Fall 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 die Größenbeschränkungen, die http.sys erzwingen. Dieses Problem wird zusammen mit der Lösung unter HTTP 400 – Ungültige Anforderung (Anforderungsheader zu lang) antworten auf HTTP-Anforderungen ausführlich erläutert.