IIS での HTTP 400 エラーのトラブルシューティング

  • [アーティクル]

適用対象: インターネット インフォメーション サービス

この記事では、IIS を使用するときにさまざまな HTTP 400 エラーの原因を特定するためのトラブルシューティング手順について説明します。

概要

HTTP 要求を IIS サーバーに送信すると、HTTP クライアント (インターネット エクスプローラーなど) に次の種類のエラー メッセージが表示されることがあります。

HTTP 400Web ページが見つかりません。

ほとんどの場合、次の原因が考えられます。

  • アドレスに入力エラーが発生する可能性があります。
  • リンクをクリックすると、古くなっている可能性があります。

試すことができるもの:

  • アドレスを再入力します。
  • 前のページに戻るします。
  • Bingに移動し、必要な情報を探します。

HTTP クライアントがインターネット エクスプローラーで、[フレンドリ HTTP エラー メッセージの表示] オプションがオフになっている場合、エラーは次のようになります。

要求が正しくありません (Bad Request)

このようなシナリオでは、要求がサーバーの HTTP 解析規則を満たしていなかったか、制限時間を超えたか、IIS または HTTP.sys 受信要求が準拠する必要がある他の規則に失敗したため、IIS によってクライアントの HTTP 要求が拒否されました。 IIS は"HTTP 400 - 不正な要求" 状態をクライアントに送信し、TCP 接続を終了します。

ツール

トラブルシューティング方法

HTTP 400 条件のトラブルシューティングを行う場合、基になる問題は、クライアントが要求を IIS に送信して、HTTP.sys が強制している 1 つ以上の規則を破ったということです。 これを念頭に置いて、クライアントが IIS に送信している正確な内容を確認する必要があります。 これを行うには、不適切な要求を送信しているクライアントのネットワーク トレースをキャプチャします。 トレースを分析して、クライアントが IIS に送信する生データを確認し、IIS がクライアントに送信する生応答データを確認できます。 クライアントとサーバーが SSL 経由で通信している場合でも HTTP ヘッダーを表示できるため、 Fiddler という HTTP スニファ ツールを使用することもできます。

次に使用するデータ項目は 、C:\Windows\System32\LogFiles\HTTPERR\httperr.log ファイルです。 IIS 6.0 以降、HTTP.sys コンポーネントは、受信 HTTP 要求を IIS に渡す前に処理し、IIS 要件を満たしていない要求をブロックするコンポーネントです。 HTTP.sys が要求をブロックすると、不適切な要求とブロックされた理由に関する情報が httperr.log ファイルに記録されます。

メモ： HTTP.sys が提供する HTTP API エラー ログの詳細については、「 HTTP API でのエラー ログ記録」を参照してください。

技術的には可能ですが、クライアントが HTTP 400 応答を受け取る可能性は非常に高くはありませんが、 httperr.logに関連するログ エントリはありません。 これは、ISAPI フィルターまたは拡張機能、または IIS の HTTP モジュールが 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....?.

ブラウザーに表示されるエラー メッセージ テキストも、ネットワーク トレースの生の応答データで表示できます。

次の手順では、不適切な要求に対応するエントリの C:\Windows\System32\LogFiles\HTTPERR ディレクトリ内のhttperr.log ファイルを確認します。

#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

このシナリオでは、Reasonhttperr.log ファイルのフィールドに、問題を診断するために必要な正確な情報が提供されます。 HTTP.sys この要求の失敗の理由フレーズとしてログに記録されている FieldLength ことがわかります。 理由フレーズがわかったら、「HTTP API がログに記録するエラーの種類」セクションの表をチェックして、その説明を取得します。

FieldLength: フィールドの長さの制限を超えました。

そのため、この時点で、ブラウザーのエラー メッセージと HTTP API エラー ログから、要求に許容される長さの制限を超えた HTTP ヘッダーのいずれかにデータが含まれていることがわかっています。 この例では、 HTTP: Uniform Resource Identifier header は意図的に長いです: /1234567890123456789012345678901234567890/time.asp。

この例のトラブルシューティングの最後の段階では、IIS の HTTP.sys レジストリ キーと既定の設定をチェックします

理由フレーズとエラーがヘッダー フィールドの長さが制限を超えていることを示唆していることがわかっているので、 レジストリ キー テーブルで検索を絞り込むことができます。 ここでの主要な候補は次のとおりです。

レジストリ キー 既定値 有効な値範囲 レジストリ キー関数 警告コード
MaxFieldLength 16384 64 から 65534 (64k - 2) バイト 各ヘッダーの上限を設定します。 MaxRequestBytes を参照してください。 この制限は、URL の約 32,000 文字に変換されます。 1

この例でこのエラーを再現するために、レジストリ キーの MaxFieldLength 値が 2 に設定されました。 要求された URL には 2 文字を超えるフィールドがあるため HTTP: Uniform Resource Identifier header 、要求は理由フレーズで FieldLength ブロックされました。

もう 1 つの一般的な HTTP 400 シナリオは、HTTP 要求を行うユーザーが多数の Active Directory グループのメンバーであり、Web サイトがユーザー Kerberos 認証に構成されているシナリオです。 この場合、次のようなエラー メッセージがユーザーに表示されます。

不適切な要求 (要求ヘッダーが長すぎます)

このシナリオでは、クライアントの HTTP 要求の一部として含まれる認証トークンが大きすぎて、http.sys が強制しているサイズ制限を超えています。 この問題は、 HTTP 400 - HTTP 要求に対する不適切な要求 (要求ヘッダーが長すぎる) 応答で、ソリューションと共に詳細に説明されています。

関連情報