HTTP 400-fouten in IIS oplossen
Van toepassing op: Internet Information Services
In dit artikel worden de stappen voor probleemoplossing beschreven voor het identificeren van de oorzaak van verschillende HTTP 400-fouten bij het gebruik van IIS.
Overzicht
Nadat een HTTP-client (zoals Microsoft Edge) een HTTP-aanvraag naar een IIS-server heeft verzonden, wordt mogelijk het volgende type foutbericht weergegeven:
HTTP 400 - Ongeldige aanvraag
In dit scenario weigert IIS de HTTP-aanvraag van de client omdat de aanvraag niet voldoet aan de HTTP-parseringsregels van de server, de tijdslimiet overschrijdt of een aantal andere regels waarvoor IIS of HTTP.sys binnenkomende aanvragen vereist om te voldoen aan. IIS stuurt de HTTP 400 - Bad Request status terug naar de client en beëindigt vervolgens de TCP-verbinding.
Hulpprogramma's
- Network Monitor
- HTTP-foutlogboekregistratie
Probleemoplossingsmethoden
Bij het oplossen van problemen met een HTTP 400-voorwaarde is het belangrijk te onthouden dat de client een aanvraag heeft verzonden naar IIS die een of meer regels onderbreekt die HTTP.sys afdwingt. Met dat in gedachten wilt u zien wat de client precies naar IIS verzendt. Als u dit wilt doen, legt u een netwerktrace vast van de client die de onjuiste aanvraag verzendt. U kunt de tracering analyseren om de onbewerkte gegevens te zien die de client naar IIS verzendt en om de onbewerkte antwoordgegevens te zien die IIS naar de client verzendt. U kunt ook een HTTP-sniffer-hulpprogramma met de naam Fiddler gebruiken, een geweldig hulpprogramma, omdat u hiermee de HTTP-headers kunt zien, zelfs als de client en server via SSL communiceren.
Het volgende gegevensitem dat u gebruikt, is het bestand C:\Windows\System32\LogFiles\HTTPERR\httperr.log . In IIS verwerkt het HTTP.sys-onderdeel binnenkomende HTTP-aanvragen voordat ze worden doorgegeven aan IIS en verantwoordelijk is voor het blokkeren van aanvragen die niet voldoen aan de IIS-vereisten. Wanneer HTTP.sys de aanvraag blokkeert, worden de gegevens in het httperr.log bestand met betrekking tot de ongeldige aanvraag en waarom deze is geblokkeerd.
Notitie
Zie Foutlogboekregistratie in HTTP-API voor meer informatie over de logboekregistratie van HTTP-API's die HTTP.sys biedt.
Het is technisch mogelijk, hoewel niet erg waarschijnlijk, dat een client mogelijk een HTTP 400-antwoord ontvangt, dat geen gekoppelde logboekvermelding heeft in het httperr.log-bestand . Dit kan gebeuren als een ISAPI-filter of extensie, of een HTTP-module in IIS, de 400-status instelt. In dat geval kunt u het IIS-logboek bekijken voor meer informatie. Dit kan ook gebeuren als een entiteit tussen de client en de server, zoals een proxyserver of een ander netwerkapparaat, een antwoord van IIS onderschept en overschrijft met een eigen 400-status en/of 'Ongeldige aanvraag'-fout.
Notitie
In dit artikel worden voornamelijk de veelvoorkomende HTTP 400-fouten besproken voordat u uw website bereikt. In sommige scenario's kan uw website ook HTTP 400-fouten retourneren aan clients vanwege de configuratie van aangepaste codelogica of runtime (zoals ASP.NET). Als u de HTTP 400-fouten nog steeds niet kunt oplossen nadat u de stappen in de volgende secties hebt uitgevoerd, probeert u het probleem op te lossen met behulp van de functie Tracering van mislukte aanvragen in IIS. Als u merkt dat de HTTP 400-fouten daadwerkelijk worden ingesteld door de bijbehorende runtime-handler van uw website, zoals ASP.NET, moet u mogelijk de details van de aanvragen en antwoorden controleren, samen met de bijbehorende codelogica en runtimeconfiguratie van uw website, om de oorzaak van de HTTP 400-fouten te begrijpen.
Voorbeeldscenario
Hieronder volgt een voorbeeld van een HTTP 400-scenario, waarbij een client een ongeldige aanvraag naar IIS verzendt en de server een bericht 'HTTP 400 - Ongeldige aanvraag' retourneert.
Wanneer de client de aanvraag verzendt, ziet de browserfout er als volgt uit:
Ongeldige aanvraag (veld koptekst te lang)
Als u een netwerktracering van de aanvraag en het antwoord vastlegt, ziet u de volgende uitvoer:
VERZOEK:
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)
ANTWOORD:
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)
U ziet dat de antwoordheaders niet zoveel vertellen als het foutbericht in de browser. Als u echter naar de onbewerkte gegevens in de hoofdtekst van het antwoord kijkt, ziet u meer:
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....?.
U kunt zien dat de tekst van het foutbericht die in de browser wordt weergegeven, ook kan worden weergegeven in de onbewerkte antwoordgegevens in de netwerktracering.
De volgende stap is het bekijken van het httperr.log bestand in de map C:\Windows\System32\LogFiles\HTTPERR voor de vermelding die overeenkomt met de ongeldige aanvraag:
#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 dit scenario bevat het Reason veld in het httperr.log-bestand de exacte informatie die u nodig hebt om het probleem vast te stellen. U ziet dat HTTP.sys geregistreerd FieldLength als de redenzin voor de fout van deze aanvraag. Zodra u de redenzin kent, controleert u de tabel in soorten fouten die in de sectie http-API-logboeken worden beschreven om de beschrijving op te halen:
FieldLength: er is een limiet voor veldlengte overschreden.
Op dit punt weet u dus van het foutbericht van de browser en de logboekregistratie van http-API-fouten dat de aanvraag gegevens bevat in een van de HTTP-headers die de toegestane lengtelimieten hebben overschreden. In dit voorbeeld is het HTTP: Uniform Resource Identifier header doelbewust lang: /1234567890123456789012345678901234567890/time.asp.
De laatste fase van het oplossen van problemen in dit voorbeeld is het controleren van de HTTP.sys registersleutels en de standaardinstellingen voor IIS
Aangezien u weet dat de redenterm en fout een veldlengte voorstellen die de limieten overschrijdt, kunt u onze zoekopdracht in de tabel Registersleutels als zodanig beperken. De belangrijkste kandidaat hier is:
| Registersleutel | Default value | Geldig waardebereik | Registersleutel, functie | WAARSCHUWINGscode |
|---|---|---|---|---|
MaxFieldLength |
16384 | 64 - 65534 (64k - 2) bytes | Hiermee stelt u een bovengrens in voor elke koptekst. Zie MaxRequestBytes. Deze limiet wordt omgezet in ongeveer 32.000 tekens voor een URL. |
1 |
Om deze fout voor dit voorbeeld te reproduceren, is de MaxFieldLength registersleutel ingesteld met de waarde 2. Omdat de aangevraagde URL een HTTP: Uniform Resource Identifier header veld met meer dan twee tekens had, werd de aanvraag geblokkeerd met de FieldLength redenzin.
Een ander veelvoorkomend HTTP 400-scenario is een scenario waarbij de gebruiker die de HTTP-aanvraag doet lid is van een groot aantal Active Directory-groepen en de website is geconfigureerd voor kerberos-verificatie van gebruikers. Wanneer dit scenario zich voordoet, wordt er een foutbericht weergegeven dat lijkt op de volgende voor de gebruiker:
Ongeldige aanvraag (aanvraagheader te lang)
In dit scenario is het verificatietoken dat is opgenomen als onderdeel van de HTTP-aanvraag van de client te groot en overschrijdt de groottelimieten die http.sys afdwingt. Dit probleem wordt in detail besproken, samen met de oplossing, in HTTP 400 - Ongeldige aanvraag (aanvraagheader te lang) antwoorden op HTTP-aanvragen.