Dela via

Felsöka HTTP 400-fel i IIS

  • Artikel

Gäller för: Internet Information Services

I den här artikeln beskrivs felsökningsstegen för att identifiera orsaken till olika HTTP 400-fel när du använder IIS.

Översikt

När en HTTP-klient (till exempel Microsoft Edge) skickar en HTTP-begäran till en IIS-server kan följande typ av felmeddelande visas:

HTTP 400 – Felaktig begäran

I det här scenariot avvisar IIS klientens HTTP-begäran eftersom begäran inte uppfyller serverns HTTP-parsningsregler, överskrider tidsgränser eller misslyckas med vissa andra regler som IIS eller HTTP.sys kräver inkommande begäranden att följa. IIS skickar tillbaka statusen HTTP 400 - Bad Request till klienten och avslutar sedan TCP-anslutningen.

Verktyg

Metoder för felsökning

När du felsöker ett HTTP 400-villkor är det viktigt att komma ihåg att det underliggande problemet är att klienten har skickat en begäran till IIS som bryter mot en eller flera regler som HTTP.sys framtvingar. Med det i åtanke vill du se exakt vad klienten skickar till IIS. Det gör du genom att samla in en nätverksspårning av klienten som skickar den felaktiga begäran. Du kan analysera spårningen för att se rådata som klienten skickar till IIS och för att se rådata som IIS skickar tillbaka till klienten. Du kan också använda ett HTTP-snifferverktyg som heter Fiddler, ett bra verktyg eftersom du kan se HTTP-huvudena även om klienten och servern kommunicerar via SSL.

Nästa dataobjekt som du använder är filen C:\Windows\System32\LogFiles\HTTPERR\httperr.log . I IIS hanterar HTTP.sys-komponenten inkommande HTTP-begäranden innan de skickas vidare till IIS och ansvarar för att blockera begäranden som inte uppfyller IIS-kraven. När HTTP.sys blockerar begäran loggar den information till sin httperr.log fil om den felaktiga begäran och varför den blockerades.

Kommentar

Mer information om HTTP API-felloggning som HTTP.sys tillhandahåller finns i Felloggning i HTTP API.

Det är tekniskt möjligt, även om det inte är särskilt troligt, att en klient kan få ett HTTP 400-svar, som inte har någon associerad loggpost i httperr.log-filen. Det kan inträffa om ett ISAPI-filter eller -tillägg, eller en HTTP-modul i IIS, anger statusen 400, i vilket fall du kan titta på IIS-loggen för mer information. Det kan också inträffa om en entitet mellan klienten och servern, till exempel en proxyserver eller annan nätverksenhet, fångar upp ett svar från IIS och åsidosätter det med sin egen 400-status och/eller "Felaktig begäran"-fel.

Kommentar

I den här artikeln beskrivs främst vanliga HTTP 400-fel innan du når din webbplats. I vissa scenarier kan din webbplats också returnera HTTP 400-fel till klienter på grund av anpassad kodlogik eller körningskonfiguration (till exempel ASP.NET). Om du fortfarande inte kan lösa HTTP 400-felen när du har utfört stegen i följande avsnitt kan du försöka felsöka med hjälp av spårningsfunktionen Misslyckade förfrågningar i IIS. Om du upptäcker att HTTP 400-felen faktiskt anges av webbplatsens motsvarande körningshanterare, till exempel ASP.NET, kan du behöva granska informationen om begäranden och svar, tillsammans med webbplatsens relaterade kodlogik och körningskonfiguration, för att förstå orsaken till HTTP 400-felen.

Exempelscenario

Följande är ett exempel på ett HTTP 400-scenario, där en klient skickar en felaktig begäran till IIS och servern skickar tillbaka meddelandet "HTTP 400 – Felaktig begäran".

När klienten skickar sin begäran ser webbläsarfelet tillbaka ut så här:

Felaktig begäran (rubrikfältet är för långt)

När du samlar in en nätverksspårning av begäran och svaret ser du följande utdata:

BEGÄRAN:

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)

SVAR:

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)

Du märker att svarshuvudena inte berättar lika mycket som felmeddelandet i webbläsaren. Men om du tittar på rådata i svarstexten ser du mer:

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....?.

Du kan se att felmeddelandetexten som visas i webbläsaren också kan visas i rådata i nätverksspårningen.

Nästa steg är att titta på filen httperr.log i katalogen C:\Windows\System32\LogFiles\HTTPERR för posten som motsvarar den felaktiga begäran:

#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

I det här scenariot Reason innehåller fältet i filen httperr.log exakt den information du behöver för att diagnostisera problemet. Du ser att HTTP.sys loggas FieldLength som orsaksfras för den här begärans misslyckande. När du känner till orsaksfrasen kontrollerar du tabellen i Typer av fel som avsnittet HTTP API loggar för att hämta dess beskrivning:

FieldLength: En gräns för fältlängd överskreds.

Så nu vet du från webbläsarens felmeddelande och HTTP API-felloggningen att begäran innehöll data i en av dess HTTP-huvuden som överskred de tillåtna längdgränserna. I det här exemplet är den målmedvetet HTTP: Uniform Resource Identifier header lång: /1234567890123456789012345678901234567890/time.asp.

Det sista steget i felsökningen av det här exemplet är att kontrollera HTTP.sys registernycklar och standardinställningar för IIS

Eftersom du vet att orsaksfrasen och felet tyder på att en rubrikfältlängd överskrider gränserna kan du begränsa sökningen i tabellen Registernycklar som sådan. Den främsta kandidaten här är:

Registernyckel Standardvärde Giltigt värdeintervall Funktionen Registernyckel VARNINGSkod
MaxFieldLength 16384 64–65534 (64–2) byte Anger en övre gräns för varje rubrik. Se MaxRequestBytes. Den här gränsen översätts till cirka 32 000 tecken för en URL. 1

För att återskapa det här felet för det här exemplet MaxFieldLength angavs registernyckeln med värdet 2. Eftersom den begärda URL:en hade ett HTTP: Uniform Resource Identifier header fält med fler än två tecken blockerades begäran med FieldLength orsaksfrasen.

Ett annat vanligt HTTP 400-scenario är ett där användaren som gör HTTP-begäran är medlem i ett stort antal Active Directory-grupper och webbplatsen är konfigurerad för kerberos-autentisering. När det här scenariot inträffar visas ett felmeddelande som liknar följande för användaren:

Felaktig begäran (begärandehuvudet är för långt)

I det här scenariot är autentiseringstoken som ingår som en del av klientens HTTP-begäran för stor och överskrider de storleksgränser som http.sys framtvingar. Det här problemet beskrivs i detalj, tillsammans med lösningen, i HTTP 400 - Felaktig begäran (begärandehuvudet är för långt) svar på HTTP-begäranden.

Referenser