共用方式為

HTTP 伺服器 API 錯誤記錄的格式

一般而言，HTTP Server API 錯誤記錄檔的格式與 W3C 錯誤記錄檔相同，但 HTTP Server API 錯誤記錄檔不包含數據行標題。 HTTP Server API 錯誤記錄檔的每一行都會以特定順序記錄一個含有字段的錯誤。 每個欄位都會以單一空格字元（0x0020）與上述欄位隔開。 在每個欄位中，空格符、索引標籤和不可列印的控制字元會取代加號（0x002B）。

下表會識別錯誤記錄檔記錄中的欄位和欄位順序。

田 描述
日期
 [日期] 字段會遵循 W3C 格式，並以國際標準時間 （UTC） 為基礎。[日期] 欄位一律為 10 個字元，格式為 “YYYY-MM-DD”。 例如，2003年5月1日會以 “2003-05-01” 表示。
時間
 [時間] 欄位會遵循 W3C 格式，並以 UTC 為基礎。 時間欄位一律為 8 個字元，格式為 「MM：HH：SS」。。 例如，下午 5：30 （UTC） 會以 “17：30：00” 表示。
用戶端IP位址
 受影響用戶端的IP位址，可以是IPv4位址或IPv6位址。 如果用戶端 IP 位址是 IPv6 位址，位址中也會包含 ScopeId 字段。
用戶端埠
 受影響客戶端的埠號碼。
伺服器 IP 位址
 受影響伺服器的IP位址，可以是IPv4位址或IPv6位址。 如果伺服器 IP 位址是 IPv6 位址，位址中也會包含 ScopeId 欄位。
伺服器埠
 受影響伺服器的埠號碼。
通訊協定版本
 所使用的通訊協定版本。
  • 如果連線剖析不足以判斷通訊協定版本，則會使用連字元 （0x002D） 做為空白欄位的佔位元。
  • 如果剖析的主要或次要版本號碼大於或等於 10，則會將版本記錄為 “HTTP/?.?”。
動詞
 最後一個剖析要求所傳遞的動詞狀態。 包含未知的動詞，但任何超過 255 個字節的動詞會截斷為這個長度。 如果無法使用動詞，則連字元 （0x002D） 會當做空白字段的佔位元使用。
CookedURL + 查詢
 URL 和與其相關聯的任何查詢都會記錄為一個字段，並以問號分隔（0x3F）。 此欄位的長度限制為 4096 個字節，因此遭到截斷。
  • 如果已剖析此 URL（“cooked”），則會使用本機代碼頁轉換來記錄，並視為 Unicode 字段。
  • 如果記錄時尚未剖析此 URL（“cooked”），則會完全複製該 URL，而不需要任何 Unicode 轉換。
  • 如果 HTTP 伺服器 API 無法剖析此 URL，則會使用連字元 （0x002D） 作為空白欄位的佔位元。
通訊協議狀態
 通訊協議狀態不能超過999。
  • 如果要求的回應的通訊協議狀態可用，則會在此欄位中記錄它。
  • 如果通訊協議狀態無法使用，則會使用連字元 （0x002D） 作為空白字段的佔位元。
SiteId
 這個版本的 HTTP 伺服器 API 中未使用。 佔位元連字元 （0x002D） 一律會出現在此欄位中。
原因片語
 此欄位包含字串，可識別所記錄的錯誤種類。 它永遠不會留空。

下列范例行來自 HTTP Server API 錯誤記錄檔：

2002-07-05 18:45:09 172.31.77.6 2094 172.31.77.6 80 
                    HTTP/1.1 GET /qos/1kbfile.txt 503 - ConnLimit
2002-07-05 19:51:59 127.0.0.1 2780 127.0.0.1 80 
                    HTTP/1.1 GET /ThisIsMyUrl.htm 400 - Hostname
2002-07-05 19:53:00 127.0.0.1 2894 127.0.0.1 80 
                    HTTP/2.0 GET / 505 - Version_N/S
2002-07-05 20:06:01 172.31.77.6 64388 127.0.0.1 80 
                    - - - - - Timer_MinBytesPerSecond
  • Last updated on