Udostępnij za pośrednictwem

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

  • Artykuł

Dotyczy: Internetowe usługi informacyjne

W tym artykule opisano kroki rozwiązywania problemów w celu zidentyfikowania przyczyny różnych błędów HTTP 400 podczas korzystania z usług IIS.

Omówienie

Po wysłaniu żądania HTTP do serwera usług IIS klient HTTP (taki jak Internet Explorer) może wyświetlić następujący typ komunikatu o błędzie:

HTTP 400Nie można odnaleźć strony internetowej.

Najbardziej prawdopodobne przyczyny:

  • W adresie może wystąpić błąd wpisywania.
  • Kliknięcie linku może być nieaktualne.

Co możesz spróbować:

  • Wpisz ponownie adres.
  • Wstecz do poprzedniej strony.
  • Przejdź do usługi Bing i poszukaj odpowiednich informacji.

Jeśli klient HTTP to Internet Explorer, a opcja Pokaż przyjazne komunikaty o błędach HTTP jest wyłączona, błąd może wyglądać następująco:

Nieprawidłowe żądanie

W tych scenariuszach usługi IIS odrzuciły żądanie HTTP klienta, ponieważ żądanie nie spełniało reguł analizy HTTP serwera, przekroczyło limity czasu lub nie powiodło się innej reguły, do których usługi IIS lub HTTP.sys wymagają przestrzegania żądań przychodzących. Usługi IIS wysyłają stan "HTTP 400 — złe żądanie" z powrotem do klienta, a następnie przerywa połączenie TCP.

Narzędzia

Metody rozwiązywania problemów

Podczas rozwiązywania problemów z warunkiem HTTP 400 należy pamiętać, że podstawowym problemem jest to, że klient wysłał żądanie do usług IIS, które łamie co najmniej jedną regułę, która HTTP.sys wymusza. Mając to na uwadze, warto 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ć ślad, aby wyświetlić nieprzetworzone dane wysyłane przez klienta do usług IIS oraz wyświetlić nieprzetworzone dane odpowiedzi wysyłane przez usługi IIS z powrotem do klienta. Możesz również użyć narzędzia do wykrywania http o nazwie Fiddler, doskonałego narzędzia, ponieważ umożliwia wyświetlanie nagłówków 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 . Począwszy od usług IIS 6.0, składnik HTTP.sys obsługuje przychodzące żądania HTTP przed ich przekazaniem do usług IIS i jest składnikiem odpowiedzialnym 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.

UWAGA: Aby uzyskać więcej informacji na temat rejestrowania błędów interfejsu API HTTP, które HTTP.sys zapewnia, zobacz Rejestrowanie błędów w interfejsie API HTTP.

Jest technicznie możliwe, chociaż nie jest bardzo prawdopodobne, że klient może otrzymać odpowiedź HTTP 400, która nie ma skojarzonego wpisu dziennika w httperr.log. Może się to zdarzyć, jeśli filtr isapi lub rozszerzenie lub moduł HTTP w usługach IIS ustawia stan 400, w którym to przypadku można przyjrzeć się dziennikowi usług IIS, aby uzyskać więcej informacji. Może się to również zdarzyć, jeśli jednostka między klientem a serwerem, na przykład serwer proxy lub inne urządzenie sieciowe, przechwyci odpowiedź z usług IIS i zastąpi 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".

Gdy klient wysyła żądanie, zwracany błąd przeglądarki wygląda następująco:

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

Przechwytywanie śledzenia sieci żądania i odpowiedzi powoduje wyświetlenie następujących danych wyjściowych:

ŻĄDANIE:

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)

ODPOWIEDZI:

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ą tyle, ile komunikat o błędzie w przeglądarce. Jeśli jednak przyjrzysz się pierwotnym 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....?.

Widać, ż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 przyjrzenie się plikowi httperr.log w katalogu C:\Windows\System32\LogFiles\HTTPERR dla wpisu, który odpowiada 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 dzienników interfejsu API HTTP , aby uzyskać jej opis:

FieldLength: przekroczono limit długości pola.

Na tym etapie wiadomo więc z komunikatu o błędzie przeglądarki i rejestrowania błędu interfejsu API HTTP, że żądanie zawiera dane w jednym z nagłówków HTTP, które przekroczyły dopuszczalne limity długości. W tym przykładzie HTTP: Uniform Resource Identifier header wartość jest celowo długa: /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ż wiesz, że fraza przyczyny i błąd sugerują, że długość pola nagłówka przekracza limity, możesz zawęzić nasze wyszukiwanie w tabeli Klucze rejestru jako takie. Głównym kandydatem jest:

Klucz rejestru Wartość domyślna Prawidłowy zakres wartości Funkcja klucza rejestru KOD OSTRZEGAWCZY
MaxFieldLength 16384 64 - 65534 (64k - 2) bajty Ustawia górny limit dla każdego nagłówka. Zobacz MaxRequestBytes. Ten limit przekłada się na około 32 tys. znaków dla adresu URL. 1

Aby odtworzyć ten błąd dla tego przykładu 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 za pomocą frazy przyczyny FieldLength .

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 przypadku 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 dołączony do żą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 odpowiedziach HTTP 400 — nieprawidłowe żądanie (zbyt długi nagłówek żądania) na żądania HTTP.

Informacje