Rozwiązywanie problemów z błędami HTTP 400 w usługach IIS

Dotyczy: Internet Information Services

W tym artykule opisano kroki rozwiązywania problemów, aby zidentyfikować przyczynę różnych błędów HTTP 400 podczas korzystania z usług IIS.

Omówienie

Po wysłaniu żądania HTTP przez klienta HTTP (takiego jak Microsoft Edge) do serwera usług IIS może zostać wyświetlony następujący typ komunikatu o błędzie:

HTTP 400 — nieprawidłowe żądanie

W tym scenariuszu usługi IIS odrzucają żądanie HTTP klienta, ponieważ żądanie nie spełnia reguł analizowania HTTP serwera, przekracza limity czasu lub kończy się niepowodzeniem niektórych innych reguł, do których usługi IIS lub HTTP.sys wymagają przestrzegania żądań przychodzących. Usługi IIS wysyła HTTP 400 - Bad Request stan z powrotem do klienta, a następnie przerywa połączenie TCP.

Narzędzia

• Microsoft Network Monitor
• Rejestrowanie błędów HTTP

Metody rozwiązywania problemów

Podczas rozwiązywania problemów z warunkiem HTTP 400 należy pamiętać, że podstawowym problemem jest wysłanie żądania do usług IIS, które przerywają jedną lub więcej reguł, które HTTP.sys wymuszają. Mając to na uwadze, należy zobaczyć, co dokładnie klient wysyła do usług IIS. Aby to zrobić, przechwyć ślad sieciowy klienta wysyłającego nieprawidłowe żądanie. Możesz przeanalizować dane śledzenia, aby zobaczyć nieprzetworzone dane wysyłane przez klienta do usług IIS i zobaczyć nieprzetworzone dane odpowiedzi wysyłane przez usługi IIS z powrotem do klienta. Można również użyć narzędzia sniffer HTTP o nazwie Fiddler, doskonałe narzędzie, ponieważ pozwala zobaczyć nagłówki HTTP, nawet jeśli klient i serwer komunikują się za pośrednictwem protokołu SSL.

Następnym używanym elementem danych jest plik C:\Windows\System32\LogFiles\HTTPERR\httperr.log . W usługach IIS składnik HTTP.sys obsługuje przychodzące żądania HTTP przed przekazaniem ich do usług IIS i jest odpowiedzialny za blokowanie żądań, które nie spełniają wymagań usług IIS. Gdy HTTP.sys blokuje żądanie, rejestruje informacje w pliku httperr.log dotyczące nieprawidłowego żądania i przyczyny jego zablokowania.

Technicznie jest to możliwe, chociaż nie jest bardzo prawdopodobne, że klient może otrzymać odpowiedź HTTP 400, która nie ma skojarzonego wpisu dziennika w pliku httperr.log . Może się to zdarzyć, jeśli filtr LUB rozszerzenie ISAPI lub moduł HTTP w usługach IIS ustawia stan 400, w tym przypadku możesz przejrzeć dziennik usług IIS, aby uzyskać więcej informacji. Może się to również zdarzyć, jeśli jednostka między klientem a serwerem, takim jak serwer proxy lub inne urządzenie sieciowe, przechwytuje odpowiedź z usług IIS i zastępuje ją własnym stanem 400 i/lub błędem "Nieprawidłowe żądanie".

Przykładowy scenariusz

Poniżej przedstawiono przykład scenariusza HTTP 400, w którym klient wysyła nieprawidłowe żądanie do usług IIS, a serwer wysyła z powrotem komunikat "HTTP 400 — nieprawidłowe żądanie".

Po wysłaniu żądania przez klienta błąd przeglądarki, który zostanie zwrócony, wygląda następująco:

Nieprawidłowe żądanie (pole nagłówka jest za długie)

Przechwycenie śledzenia sieci żądania i odpowiedzi jest widoczne następujące dane wyjściowe:

PROSIĆ:

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)

ODPOWIEDŹ:

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)

Zauważysz, że nagłówki odpowiedzi nie mówią tak samo jak komunikat o błędzie w przeglądarce. Jeśli jednak przyjrzysz się nieprzetworzonym danym w treści odpowiedzi, zobaczysz więcej:

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

Zobaczysz, że tekst komunikatu o błędzie wyświetlany w przeglądarce jest również widoczny w nieprzetworzonych danych odpowiedzi w śledzeniu sieci.

Następnym krokiem jest zapoznanie się z plikiem httperr.log w katalogu C:\Windows\System32\LogFiles\HTTPERR dla wpisu odpowiadającego nieprawidłowemu żądaniu:

#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

W tym scenariuszu Reason pole w pliku httperr.log zawiera dokładne informacje potrzebne do zdiagnozowania problemu. Zobaczysz, że HTTP.sys zarejestrowane FieldLength jako fraza przyczyny niepowodzenia tego żądania. Gdy znasz frazę przyczyny, sprawdź tabelę w sekcji Rodzaje błędów w sekcji Dzienniki interfejsu API HTTP, aby uzyskać jej opis:

FieldLength: Przekroczono limit długości pola.

W tym momencie wiadomo z komunikatu o błędzie przeglądarki i rejestrowania błędów interfejsu API HTTP, że żądanie zawiera dane w jednym z nagłówków HTTP, które przekroczyły dozwolone limity długości. W tym przykładzie HTTP: Uniform Resource Identifier header parametr jest celowo długi: /1234567890123456789012345678901234567890/time.asp.

Ostatnim etapem rozwiązywania problemów z tym przykładem jest sprawdzenie HTTP.sys kluczy rejestru i ustawień domyślnych dla usług IIS

Ponieważ znasz frazę przyczyny i błąd sugerują, że długość pola nagłówka przekracza limity, możesz zawęzić nasze wyszukiwanie w tabeli Klucze rejestru, w związku z tym. Głównym kandydatem jest tutaj:

Aby odtworzyć ten błąd w tym przykładzie, MaxFieldLength klucz rejestru został ustawiony z wartością 2. Ponieważ żądany adres URL miał HTTP: Uniform Resource Identifier header pole z więcej niż dwoma znakami, żądanie zostało zablokowane z frazą FieldLength przyczyny.

Innym typowym scenariuszem HTTP 400 jest taki, w którym użytkownik wysyłający żądanie HTTP jest członkiem dużej liczby grup usługi Active Directory, a witryna internetowa jest skonfigurowana do uwierzytelniania Kerberos użytkownika. W takim scenariuszu zostanie wyświetlony komunikat o błędzie podobny do następującego:

Nieprawidłowe żądanie (nagłówek żądania jest za długi)

W tym scenariuszu token uwierzytelniania, który jest uwzględniony w ramach żądania HTTP klienta, jest zbyt duży i przekracza limity rozmiaru, które http.sys wymusza. Ten problem został szczegółowo omówiony wraz z rozwiązaniem w artykule HTTP 400 — Nieprawidłowe żądanie (nagłówek żądania zbyt długo) odpowiedzi na żądania HTTP.

Informacje

• Rejestrowanie błędów w interfejsie API HTTP