共用方式為

針對 IIS 中的 HTTP 400 錯誤進行疑難排解

  • 發行項

作者：Mike Laing

此疑難排解員中使用的工具：

  • 網路監視器
  • HTTP 錯誤記錄

此資料僅供參考之用。 Microsoft 不做任何明示或暗示的保證。

概觀

將 HTTP 要求傳送至 IIS 伺服器之後，Internet Explorer) 之類的 HTTP 用戶端 (可能會顯示下列類型的錯誤訊息：

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 傳回給用戶端的原始回應資料。 您也可以使用名為 Fiddler 的 HTTP 探測器工具;這是絕佳的工具，因為它可讓您查看 HTTP 標頭，即使用戶端和伺服器透過 SSL 進行通訊也一樣。

您要使用的下一個資料項目是 C:\Windows\System32\LogFiles\HTTPERR\httperr.log 檔案。 從 IIS 6.0 開始，HTTP.sys元件會在傳入 HTTP 要求傳遞至 IIS 之前處理傳入 HTTP 要求，而且是負責封鎖不符合 IIS 需求的要求元件。 當HTTP.sys封鎖要求時，它會將資訊記錄到其 HTTPerr.log 檔案中，這些檔案中有關錯誤的要求及其封鎖原因。

注意：如需HTTP.sys提供之 HTTP API 錯誤記錄的詳細資訊，請參閱下列文章：

雖然並非非常有可能，但用戶端會收到 HTTP 400 回應，但 HTTPerr.log 中沒有相關聯的記錄專案。 如果 IIS 中的 ISAPI 篩選或延伸模組或 HTTP 模組設定 400 狀態，在此情況下，您可以查看 IIS 記錄檔以取得詳細資訊。 如果用戶端與伺服器之間的實體，例如 Proxy 伺服器或其他網路裝置，攔截來自 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 檔案中的 Reason 欄位會提供我們診斷問題所需的確切資訊。 我們在這裡看到HTTP.sys記錄 FieldLength 作為此要求失敗的原因片語。 一旦知道原因片語，我們就可以使用上述 HTTP API 中的錯誤記錄一文來取得其描述：

FieldLength: A field length limit was exceeded.

因此，此時，我們知道瀏覽器錯誤訊息和 HTTP API 錯誤記錄，要求包含其其中一個 HTTP 標頭中的資料，超過允許的長度限制。 為了本範例的目的，HTTP：統一資源識別項標頭的用途是有目的的：/1234567890123456789012345678901234567890/time.asp。

此範例疑難排解的最後一個階段是使用下列文章來查看 IIS 的HTTP.sys登錄機碼和預設設定：

由於我們知道片語和錯誤是建議標頭欄位長度超過限制，因此我們可以縮小 KB820129 中的搜尋範圍，例如。 這裡的主要候選項目如下：

MaxFieldLength：設定每個標頭的上限。 請參閱 MaxRequestBytes。 此限制會轉譯為 URL 大約 32k 個字元。

為了重現此範例的這個錯誤，MaxFieldLength 登錄機碼設定值為 2。 由於要求的 URL 具有 HTTP：統一資源識別項標頭欄位，且超過 2 個字元，因此已使用 FieldLength 原因片語封鎖要求。

另一個常見的 HTTP 400 案例是提出 HTTP 要求的使用者是大量 Active Directory 群組的成員，而網站會設定為使用者 Kerberos 驗證。 發生這種情況時，會顯示類似下列的錯誤訊息給使用者：

不正確的要求 (要求標頭太長)

在此案例中，包含在用戶端 HTTP 要求一部分的驗證權杖太大，而且超過http.sys強制執行的大小限制。 在下列知識庫文章中，會詳細討論此問題以及解決方案：

其他資源