Share via

Устранение ошибок HTTP 400 в IIS

  • Статья

Майк Лаинг

Средства, используемые в этом средстве устранения неполадок:

  • Сетевой монитор
  • Ведение журнала ошибок HTTP

Этот материал предоставляется только в информационных целях. Корпорация Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых.

Обзор

После отправки HTTP-запроса на сервер IIS http-клиент (например, Internet Explorer) может отобразить следующее сообщение об ошибке:

HTTP 400Не удается найти веб-страницу.

Наиболее вероятные причины:

  • Возможно, сделана опечатка в адресе.
  • Если щелкнуть ссылку, возможно, она устарела.

Что можно попробовать:

  • Повторно введите адрес.
  • Вернуться к предыдущей странице
  • Перейдите в Bing и найдите нужную информацию.

Если http-клиент — Internet Explorer, а параметр "Показать понятные сообщения об ошибках HTTP" отключен, ошибка может выглядеть следующим образом:

Недопустимый запрос

В таких сценариях СЛУЖБЫ IIS отклонили HTTP-запрос клиента, так как запрос не соответствует правилам синтаксического анализа HTTP сервера или превышению ограничений времени или завершился сбоем другого правила, к которому IIS или HTTP.sys требовать соблюдения входящих запросов. IIS отправляет клиенту состояние "HTTP 400 — недопустимый запрос", а затем завершает TCP-подключение.

Методы устранения неполадок

При устранении неполадок с условием HTTP 400 важно помнить, что основная проблема заключается в том, что клиент отправил запрос в IIS, который нарушает одно или несколько правил, которые HTTP.sys применяется. Учитывая это, вы захотите точно увидеть, что клиент отправляет в IIS; для этого зафиксировать сетевую трассировку клиента, отправляющего неверный запрос. Вы можете проанализировать трассировку, чтобы просмотреть необработанные данные, отправляемые клиентом в IIS, и просмотреть необработанные данные ответа, отправляемые iis обратно клиенту. Кроме того, можно использовать средство сниффера HTTP с именем Fiddler; это отличный инструмент, так как он позволяет просматривать заголовки HTTP, даже если клиент и сервер взаимодействуют по протоколу SSL.

Следующий элемент данных, который вы хотите использовать, — C:\Windows\System32\LogFiles\HTTPERR\httperr.log это файл. Начиная с IIS 6.0 компонент HTTP.sys обрабатывает входящие HTTP-запросы перед их передачей в IIS и отвечает за блокировку запросов, которые не соответствуют требованиям IIS. Когда HTTP.sys блокирует запрос, он записывает сведения в свой файл httperr.log относительно неправильного запроса и причины его блокировки.

ПРИМЕЧАНИЕ. Дополнительные сведения о ведении журнала ошибок API HTTP, которые HTTP.sys предоставляет, см. в следующей статье:

Технически возможно, хотя и не очень вероятно, что клиент получит ответ HTTP 400, у которого нет связанной записи журнала в httperr.log. Это может произойти, если фильтр или расширение ISAPI или модуль HTTP в IIS задает состояние 400, в этом случае можно просмотреть в журнале IIS дополнительные сведения. Это также может произойти, если сущность между клиентом и сервером, например прокси-сервером или другим сетевым устройством, перехватывает ответ от СЛУЖБ IIS и переопределяет ее собственным состоянием 400 и /или ошибкой "Недопустимый запрос".

Пример сценария

Ниже приведен пример сценария HTTP 400, в котором клиент отправляет неверный запрос в IIS, а сервер отправляет сообщение HTTP 400 — недопустимый запрос.

Когда клиент отправляет свой запрос, ошибка браузера, она возвращается следующим образом:

Недопустимый запрос (поле заголовка слишком длинное)

Запись сетевой трассировки запроса и ответа отображается следующим необработанным запросом и ответом:

ЗАПРОС:

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)

ОТВЕТ:

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)

Вы заметите, что заголовки ответов не сообщают нам столько, сколько сообщение об ошибке в браузере. Однако если мы рассмотрим необработанные данные в теле отклика, мы увидим следующее:

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

Вы увидите, что текст сообщения об ошибке, отображаемый в браузере, также доступен для просмотра в необработанных данных ответа в трассировке сети.

Следующим шагом является просмотр файла httperr.log в C:\Windows\System32\LogFiles\HTTPERR каталоге для записи, соответствующей неправильному запросу:

#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

В этом сценарии поле "Причина" в файле httperr.log предоставляет нам точные сведения, необходимые для диагностики проблемы. Мы видим здесь, что HTTP.sys в журнал FieldLength в качестве фразы причины сбоя этого запроса. Как только мы узнаем причину, мы можем использовать ведение журнала ошибок в статье API HTTP, упомянутой выше, чтобы получить его описание:

FieldLength: A field length limit was exceeded.

Поэтому на этом этапе мы знаем из сообщения об ошибке браузера и журнала ошибок API HTTP, что запрос содержит данные в одном из заголовков HTTP, которые превысили допустимые ограничения длины. В этом примере заголовок HTTP: универсальный идентификатор ресурса имеет целевое значение: /1234567890123456789012345678901234567890/time.asp.

Последним этапом устранения неполадок этого примера является использование следующей статьи, чтобы просмотреть разделы реестра HTTP.sys и параметры по умолчанию для IIS:

Так как мы знаем, что фраза причины и ошибка предлагают длину поля заголовка, превышающую ограничения, мы можем сузить поиск в KB820129 таким образом. Главный кандидат здесь:

MaxFieldLength: задает верхний предел для каждого заголовка. См. статью MaxRequestBytes. Это ограничение преобразуется примерно в 32 кб символов для URL-адреса.

Чтобы воспроизвести эту ошибку для этого примера, для раздела реестра MaxFieldLength было задано значение 2. Так как запрошенный URL-адрес имел поле заголовка HTTP: универсальный идентификатор ресурса с более чем 2 символами, запрос был заблокирован с помощью фразы причины FieldLength.

Другой распространенный сценарий HTTP 400 — это сценарий, в котором пользователь, выполняющий HTTP-запрос, является членом большого количества групп Active Directory, а веб-сайт настроен для проверки подлинности Kerberos. В этом случае пользователю будет отображаться сообщение об ошибке, аналогичное следующему:

Недопустимый запрос (слишком длинный заголовок запроса)

В этом сценарии маркер проверки подлинности, включенный в состав HTTP-запроса клиента, слишком велик и превышает ограничения размера, которые http.sys применяется. Эта проблема подробно рассматривается вместе с решением в следующей статье базы знаний:

Другие ресурсы