3xx重定向

**HTTP 狀態碼**（英語：HTTP Status Code）是用以表示網頁伺服器超文字傳輸協定回應狀態的 3 位數字代碼。它由 RFC 2616 規範定義的，並得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774 與 RFC 4918 等規範擴充。所有狀態碼被分為五類，狀態碼的第一個數字代表了回應的五種狀態之一。所示的訊息短語是典型的，但是可以提供任何可讀取的替代方案。 除非另有說明，狀態碼是 HTTP/1.1 標準（RFC 7231）的一部分。

HTTP 狀態碼的官方登錄檔由網際網路號碼分配局（Internet Assigned Numbers Authority）維護。

## 1xx 訊息

這一類型的狀態碼，代表請求已被接受，需要繼續處理。這類回應是臨時回應，只包含狀態行和某些可選的回應頭資訊，並以空行結束。由於 HTTP/1.0 協定中沒有定義任何 1xx 狀態碼，所以除非在某些試驗條件下，伺服器禁止向此類客戶端傳送 1xx 回應。
這些狀態碼代表的回應都是資訊性的，標示客戶應該等待伺服器採取進一步行動。

**100 Continue**
: 伺服器已經接收到請求頭，並且客戶端應繼續傳送請求主體（在需要傳送身體的請求的情況下：例如，POST 請求），或者如果請求已經完成，忽略這個回應。伺服器必須在請求完成後向客戶端傳送一個最終回應。要使伺服器檢查請求的頭部，客戶端必須在其初始請求中傳送 `Expect: 100-continue` 作為頭部，並在傳送正文之前接收 `100 Continue` 狀態代碼。回應代碼 417 期望失敗表示請求不應繼續。

**101 Switching Protocols**
: 伺服器已經理解了客戶端的請求，並將通過 Upgrade 訊息頭通知客戶端採用不同的協定來完成這個請求。在傳送完這個回應最後的空行後，伺服器將會切換到在 Upgrade 訊息頭中定義的那些協定。

　
: 只有在切換新的協定更有好處的時候才應該採取類似措施。例如，切換到新的 HTTP 版本（如 HTTP/2）比舊版本更有優勢，或者切換到一個即時且同步的協定（如 WebSocket）以傳送利用此類特性的資源。

**102 Processing（WebDAV；RFC 2518）**
: WebDAV 請求可能包含許多涉及檔案操作的子請求，需要很長時間才能完成請求。該代碼表示伺服器已經收到並正在處理請求，但無回應可用。這樣可以防止客戶端逾時，並假設請求遺失。

**103 Early Hints (RFC 8297)**
: 用來在最終的 HTTP 訊息之前返回一些回應頭。

## 2xx 成功

這一類型的狀態碼，代表請求已成功被伺服器接收、理解、並接受。

**200 OK**
: 請求已成功，請求所希望的回應頭或資料體將隨此回應返回。實際的回應將取決於所使用的請求方法。在 GET 請求中，回應將包含與請求的資源相對應的實體。在 POST 請求中，回應將包含描述或操作結果的實體。

**201 Created**
: 請求已經被實現，而且有一個新的資源已經依據請求的需要而建立，且其 URI 已經隨 Location 頭資訊返回。假如需要的資源無法及時建立的話，應當返回 '202 Accepted'。

**202 Accepted**
: 伺服器已接受請求，但尚未處理。最終該請求可能會也可能不會被執行，並且可能在處理發生時被禁止。

**203 Non-Authoritative Information（自 HTTP / 1.1 起）**
: 伺服器是一個轉換代理伺服器（transforming proxy，例如網路加速器），以 `200 OK` 狀態碼為起源，但回應了原始回應的修改版本。

**204 No Content**
: 伺服器成功處理了請求，沒有返回任何內容。在強制門戶功能中，Wi-Fi 裝置連接到需要進行 Web 認證的 Wi-Fi 存取點時，通過存取一個能生成 HTTP 204 回應的的網站，如果能正常收到 204 回應，則代表無需 Web 認證，否則會彈出網頁瀏覽器介面，顯示出 Web 網頁認證介面用於讓使用者認證登入。

**205 Reset Content**
: 伺服器成功處理了請求，但沒有返回任何內容。與 204 回應不同，此回應要求請求者重設文件視圖。

**206 Partial Content（RFC 7233）**
: 伺服器已經成功處理了部分 GET 請求。類似於 FlashGet 或者迅雷這類的 HTTP 下載工具都是使用此類回應實現斷點續傳或者將一個大文件分解為多個下載段同時下載。

**207 Multi-Status（WebDAV；RFC 4918）**
: 代表之後的訊息體將是一個 XML 訊息，並且可能依照之前子請求數量的不同，包含一系列獨立的回應代碼。

**208 Already Reported （WebDAV；RFC 5842）**
: DAV 繫結的成員已經在（多狀態）回應之前的部分被列舉，且未被再次包含。

**226 IM Used （RFC 3229）**
: 伺服器已經滿足了對資源的請求，對實體請求的一個或多個實體操作的結果表示。

## 3xx 重新導向

這類狀態碼代表需要客戶端採取進一步的操作才能完成請求。通常，這些狀態碼用來重新導向，後續的請求位址（重新導向目標）在本次回應的 Location 域中指明。

若且唯若後續的請求所使用的方法是 GET 或者 HEAD 時，使用者瀏覽器才可以在沒有使用者介入的情況下自動提交所需要的後續請求。客戶端應當自動監測無限迴圈重新導向（例如：A→B→C→……→A 或 A→A），因為這會導致伺服器和客戶端大量不必要的資源消耗。按照 HTTP/1.0 版規範的建議，瀏覽器不應自動存取超過 5 次的重新導向。

**300 Multiple Choices**
: 被請求的資源有一系列可供選擇的回饋資訊，每個都有自己特定的位址和瀏覽器驅動的商議資訊。使用者或瀏覽器能夠自行選擇一個首選的位址進行重新導向。

　
: 除非這是一個 HEAD 請求，否則該回應應當包括一個資源特性及位址的列表的實體，以便使用者或瀏覽器從中選擇最合適的重新導向位址。這個實體的格式由 Content-Type 定義的格式所決定。瀏覽器可能根據回應的格式以及瀏覽器自身能力，自動作出最合適的選擇。當然，RFC 2616 規範並沒有規定這樣的自動選擇該如何進行。

　
: 如果伺服器本身已經有了首選的回饋選擇，那麼在 Location 中應當指明這個回饋的 URI；瀏覽器可能會將這個 Location 值作為自動重新導向的位址。此外，除非額外指定，否則這個回應也是可快取的。

**301 Moved Permanently**
: 被請求的資源已永久移動到新位置，並且將來任何對此資源的參照都應該使用本回應返回的若干個 URI 之一。如果可能，擁有連結編輯功能的客戶端應當自動把請求的位址修改為從伺服器回饋回來的位址。除非額外指定，否則這個回應也是可快取的。

　
: 新的永久性的 URI 應當在回應的 Location 域中返回。除非這是一個 HEAD 請求，否則回應的實體中應當包含指向新的 URI 的超連結及簡短說明。

　
: 如果這不是一個 GET 或者 HEAD 請求，那麼瀏覽器禁止自動進行重新導向，除非得到使用者的確認，因為請求的條件可能因此發生變化。

　
: 注意：對於某些使用 HTTP/1.0 協定的瀏覽器，當它們傳送的 POST 請求得到了一個 301 回應的話，接下來的重新導向請求將會變成 GET 方式。

**302 Found**
: 要求客戶端執行臨時重新導向（原始描述短語為「Moved Temporarily」）。由於這樣的重新導向是臨時的，客戶端應當繼續向原有位址傳送以後的請求。只有在 Cache-Control 或 Expires 中進行了指定的情況下，這個回應才是可快取的。

　
: 新的臨時性的 URI 應當在回應的 Location 域中返回。除非這是一個 HEAD 請求，否則回應的實體中應當包含指向新的 URI 的超連結及簡短說明。

　
: 如果這不是一個 GET 或者 HEAD 請求，那麼瀏覽器禁止自動進行重新導向，除非得到使用者的確認，因為請求的條件可能因此發生變化。

　
: 注意：雖然 RFC 1945 和 RFC 2068 規範不允許客戶端在重新導向時改變請求的方法，但是很多現存的瀏覽器將 302 回應視作為 303 回應，並且使用 GET 方式存取在 Location 中規定的 URI，而無視原先請求的方法。因此狀態碼 303 和 307 被添加了進來，用以明確伺服器期待客戶端進行何種反應。

**303 See Other**
: 對應當前請求的回應可以在另一個 URI 上被找到，當回應於 POST（或 PUT / DELETE）接收到回應時，客戶端應該假定伺服器已經收到資料，並且應該使用單獨的 GET 訊息發出重新導向。這個方法的存在主要是為了允許由指令碼啟用的 POST 請求輸出重新導向到一個新的資源。這個新的 URI 不是原始資源的替代參照。同時，303 回應禁止被快取。當然，第二個請求（重新導向）可能被快取。

　
: 新的 URI 應當在回應的 Location 域中返回。除非這是一個 HEAD 請求，否則回應的實體中應當包含指向新的 URI 的超連結及簡短說明。

　
: 注意：許多 HTTP/1.1 版以前的瀏覽器不能正確理解 303 狀態。如果需要考慮與這些瀏覽器之間的互動，302 狀態碼應該可以勝任，因為大多數的瀏覽器處理 302 回應時的方式恰恰就是上述規範要求客戶端處理 303 回應時應當做的。

**304 Not Modified**
: 表示資源在由請求頭中的 If-Modified-Since 或 If-None-Match 參數指定的這一版本之後，未曾被修改。在這種情況下，由於客戶端仍然具有以前下載的副本，因此不需要重新傳輸資源。

**305 Use Proxy**
: 被請求的資源必須通過指定的代理才能被存取。Location 域中將給出指定的代理所在的 URI 資訊，接收者需要重複傳送一個單獨的請求，通過這個代理才能存取相應資源。只有原始伺服器才能建立 305 回應。許多 HTTP 客戶端（像是 Mozilla）都沒有正確處理這種狀態代碼的回應，主要是出於安全考慮。

　
: 注意：RFC 2068 中沒有明確 305 回應是為了重新導向一個單獨的請求，而且只能被原始伺服器建立。忽視這些限制可能導致嚴重的安全後果。

**306 Switch Proxy**
: 在最新版的規範中，306 狀態碼已經不再被使用。最初是指「後續請求應使用指定的代理」。

**307 Temporary Redirect**
: 在這種情況下，請求應該與另一個 URI 重複，但後續的請求應仍使用原始的 URI。 與 302 相反，當重新發出原始請求時，不允許更改請求方法。 例如，應該使用另一個 POST 請求來重複 POST 請求。

**308 Permanent Redirect (RFC 7538)**
: 請求和所有將來的請求應該使用另一個 URI 重複。 307 和 308 重複 302 和 301 的行為，但不允許 HTTP 方法更改。 例如，將表單提交給永久重新導向的資源可能會順利進行。

## 4xx 客戶端錯誤

這類的狀態碼代表了客戶端看起來可能發生了錯誤，妨礙了伺服器的處理。除非回應的是一個 HEAD 請求，否則伺服器就應該返回一個解釋當前錯誤狀況的實體，以及這是臨時的還是永久性的狀況。這些狀態碼適用於任何請求方法。瀏覽器應當向使用者顯示任何包含在此類錯誤回應中的實體內容。

如果錯誤發生時客戶端正在傳送資料，那麼使用 TCP 的伺服器實現應當仔細確保在關閉客戶端與伺服器之間的連接之前，客戶端已經收到了包含錯誤資訊的封包。如果客戶端在收到錯誤資訊後繼續向伺服器傳送資料，伺服器的 TCP 棧將向客戶端傳送一個重設封包，以清除該客戶端所有還未辨識的輸入緩衝，以免這些資料被伺服器上的應用程式讀取並干擾後者。

**400 Bad Request**
: 由於明顯的客戶端錯誤（例如，格式錯誤的請求語法，太大的大小，無效的請求訊息或欺騙性路由請求），伺服器不能或不會處理該請求。

**401 Unauthorized（RFC 7235）**
: : 參見：HTTP 基本認證、HTTP 摘要認證

　
: 類似於 403 Forbidden，401 語意即「未認證」，即使用者沒有必要的憑據。該狀態碼表示當前請求需要使用者驗證。該回應必須包含一個適用於被請求資源的 WWW-Authenticate 資訊頭用以詢問使用者資訊。客戶端可以重複提交一個包含恰當的 Authorization 頭資訊的請求。如果當前請求已經包含了 Authorization 憑證，那麼 401 回應代表著伺服器驗證已經拒絕了那些憑證。如果 401 回應包含了與前一個回應相同的身分驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那麼瀏覽器應當向使用者展示回應中包含的實體資訊，因為這個實體資訊中可能包含了相關診斷資訊。

　
: 注意：當網站（通常是網站域名）禁止 IP 位址時，有些網站狀態碼顯示的 401，表示該特定位址被拒絕存取網站。

**402 Payment Required**
: 該狀態碼是為了將來可能的需求而預留的。該狀態碼最初的意圖可能被用作某種形式的數字現金或線上支付方案的一部分，但幾乎沒有哪家服務商使用，而且這個狀態碼通常不被使用。如果特定開發人員已超過請求的每日限制，Google Developers API 會使用此狀態碼。

**403 Forbidden**

　
: 伺服器已經理解請求，但是拒絕執行它。與 401 回應不同的是，身分驗證並不能提供任何幫助，而且這個請求也不應該被重複提交。如果這不是一個 HEAD 請求，而且伺服器希望能夠講清楚為何請求不能被執行，那麼就應該在實體內描述拒絕的原因。當然伺服器也可以返回一個 404 回應，假如它不希望讓客戶端獲得任何資訊。

**404 Not Found**

　
: 請求失敗，請求所希望得到的資源未被在伺服器上發現，但允許使用者的後續請求。沒有資訊能夠告訴使用者這個狀況到底是暫時的還是永久的。假如伺服器知道情況的話，應當使用 410 狀態碼來告知舊資源因為某些內部的組態機制問題，已經永久的不可用，而且沒有任何可以跳轉的位址。404 這個狀態碼被廣泛應用於當伺服器不想揭示到底為何請求被拒絕或者沒有其他適合的回應可用的情況下。

**405 Method Not Allowed**
: 請求行中指定的請求方法不能被用於請求相應的資源。該回應必須返回一個 Allow 頭資訊用以表示出當前資源能夠接受的請求方法的列表。例如，需要通過 POST 呈現資料的表單上的 GET 請求，或唯讀資源上的 PUT 請求。

　
: 鑑於 PUT，DELETE 方法會對伺服器上的資源進行寫操作，因而絕大部分的網頁伺服器都不支援或者在預設組態下不允許上述請求方法，對於此類請求均會返回 405 錯誤。

**406 Not Acceptable**
: : 參見：內容協商

　
: 請求的資源的內容特性無法滿足請求頭中的條件，因而無法生成回應實體，該請求不可接受。

　
: 除非這是一個 HEAD 請求，否則該回應就應當返回一個包含可以讓使用者或者瀏覽器從中選擇最合適的實體特性以及網址列表的實體。實體的格式由 Content-Type 頭中定義的媒體類型決定。瀏覽器可以根據格式及自身能力自行作出最佳選擇。但是，規範中並沒有定義任何作出此類自動選擇的標準。

**407 Proxy Authentication Required（RFC 2617）**
: 與 401 回應類似，只不過客戶端必須在代理伺服器上進行身分驗證。代理伺服器必須返回一個 Proxy-Authenticate 用以進行身分詢問。客戶端可以返回一個 Proxy-Authorization 資訊頭用以驗證。

**408 Request Timeout**
: 請求逾時。根據 HTTP 規範，客戶端沒有在伺服器預備等待的時間內完成一個請求的傳送，客戶端可以隨時再次提交這一請求而無需進行任何更改。

**409 Conflict**
: 表示因為請求存在衝突無法處理該請求，例如多個同步更新之間的編輯衝突。

**410 Gone**
: 表示所請求的資源不再可用。當資源被有意地刪除並且資源應被清除時，應該使用這個。在收到 410 狀態碼後，使用者應停止再次請求資源。但大多數伺服器端不會使用此狀態碼，而是直接使用 404 狀態碼。

**411 Length Required**
: 伺服器拒絕在沒有定義 Content-Length 頭的情況下接受請求。在添加了表明請求訊息體長度的有效 Content-Length 頭之後，客戶端可以再次提交該請求。

**412 Precondition Failed（RFC 7232）**
: 伺服器在驗證在請求的頭欄位中給出先決條件時，沒能滿足其中的一個或多個。這個狀態碼允許客戶端在取得資源時在請求的元資訊（請求頭欄位資料）中設定先決條件，以此避免該請求方法被應用到其希望的內容以外的資源上。

**413 Request Entity Too Large（RFC 7231）**
: 前稱「Request Entity Too Large」，表示伺服器拒絕處理當前請求，因為該請求提交的實體資料大小超過了伺服器願意或者能夠處理的範圍。此種情況下，伺服器可以關閉連接以免客戶端繼續傳送此請求。

　
: 如果這個狀況是臨時的，伺服器應當返回一個 Retry-After 的回應頭，以告知客戶端可以在多少時間以後重新嘗試。

**414 Request-URI Too Long（RFC 7231）**
: 前稱「Request-URI Too Long」，表示請求的 URI 長度超過了伺服器能夠解釋的長度，因此伺服器拒絕對該請求提供服務。通常將太多資料的結果編碼為 GET 請求的查詢字串，在這種情況下，應將其轉換為 POST 請求。這比較少見，通常的情況包括：
* 本應使用 POST 方法的表單提交變成了 GET 方法，導致查詢字串過長。
* 重新導向 URI「黑洞」，例如每次重新導向把舊的 URI 作為新的 URI 的一部分，導致在若干次重新導向後 URI 超長。
* 客戶端正在嘗試利用某些伺服器中存在的安全漏洞攻擊伺服器。這類伺服器使用固定長度的緩衝讀取或操作請求的 URI，當 GET 後的參數超過某個數值後，可能會產生緩衝區溢位，導致任意代碼被執行。沒有此類漏洞的伺服器，應當返回 414 狀態碼。

**415 Unsupported Media Type**
: 對於當前請求的方法和所請求的資源，請求中提交的網際網路媒體類型並不是伺服器中所支援的格式，因此請求被拒絕。例如，客戶端將圖像上傳格式為 svg，但伺服器要求圖像使用上傳格式為 jpg。

**416 Requested Range Not Satisfiable（RFC 7233）**
: 前稱「Requested Range Not Satisfiable」。客戶端已經要求檔案的一部分（Byte serving），但伺服器不能提供該部分。例如，如果客戶端要求檔案的一部分超出檔案尾端。

**417 Expectation Failed**
: 在請求頭 Expect 中指定的預期內容無法被伺服器滿足，或者這個伺服器是一個代理服顯的證據證明在當前路由的下一個節點上，Expect 的內容無法被滿足。

**418 I'm a teapot（RFC 2324，httpwg/http-core#43 （頁面存檔備份，存於網際網路檔案館））**
: 本操作碼是在 1998 年作為 IETF 的傳統愚人節笑話，在 RFC 2324 超文字咖啡壺控制協定中定義的，並不需要在真實的 HTTP 伺服器中定義，**同時也不是規範的 HTTP 狀態碼**。當一個控制茶壺的 HTCPCP 收到 BREW 或 POST 指令要求其煮咖啡時應當回傳此錯誤。這個 HTTP 狀態碼在某些網站（包括 Google.com）與項目（如 Node.js、ASP.NET 和 Go 語言）中用作彩蛋。

**421 Misdirected Request （RFC 7540）**
: 該請求針對的是無法產生回應的伺服器（例如因為連接重用）。

**422 Unprocessable Entity（WebDAV；RFC 4918 ）**
: 請求格式正確，但是由於含有語意錯誤，無法回應。

**423 Locked（WebDAV；RFC 4918）**
: 當前資源被鎖定。

**424 Failed Dependency（WebDAV；RFC 4918）**
: 由於之前的某個請求發生的錯誤，導致當前請求失敗，例如 PROPPATCH。

**425 Too Early (RFC 8470)**
: 伺服器拒絕處理在 Early Data 中的請求，以規避可能的重放攻擊。

**426 Upgrade Required（RFC 2817）**
: 客戶端應切換到 Upgrade 頭欄位中給出的不同協定，如 TLS/1.0。

**428 Precondition Required (RFC 6585)**
: 原伺服器要求該請求滿足一定條件。這是為了防止「未更新」問題，即客戶端讀取（GET）一個資源的狀態，更改它，並將它寫（PUT）回伺服器，但這期間第三方已經在伺服器上更改了該資源的狀態，因此導致了衝突。」

**429 Too Many Requests （RFC 6585）**
: 使用者在給定的時間內傳送了太多的請求。旨在用於網路限速。

**431 Request Header Fields Too Large （RFC 6585）**
: 伺服器不願處理請求，因為一個或多個頭欄位過大。

**440 Login Time-out**
: 客戶端 session 逾時失效，需要重新登入。

**451 Unavailable For Legal Reasons**

　
: 該存取因法律的要求而被拒絕，由 IETF 在 2015 核准後新增加。

## 5xx 伺服器錯誤

表示伺服器無法完成明顯有效的請求。這類狀態碼代表了伺服器在處理請求的過程中有錯誤或者異常狀態發生，也有可能是伺服器意識到以當前的軟硬體資源無法完成對請求的處理。除非這是一個 HEAD 請求，否則伺服器應當包含一個解釋當前錯誤狀態以及這個狀況是臨時的還是永久的解釋資訊實體。瀏覽器應當向使用者展示任何在當前回應中被包含的實體。這些狀態碼適用於任何回應方法。

**500 Internal Server Error**
: 通用錯誤訊息，伺服器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。沒有給出具體錯誤資訊。

**501 Not Implemented**
: 伺服器不支援當前請求所需要的某個功能。當伺服器無法辨識請求的方法，並且無法支援其對任何資源的請求。（例如，網路服務 API 的新功能）

**502 Bad Gateway**
: 作為閘道器或者代理工作的伺服器嘗試執行請求時，從上游伺服器接收到無效的回應。

**503 Service Unavailable**
: 由於臨時的伺服器維護或者過載，伺服器當前無法處理請求。這個狀況是暫時的，並且將在一段時間以後恢復。如果能夠預計延遲時間，那麼回應中可以包含一個 Retry-After 頭用以標明這個延遲時間。如果沒有給出這個 Retry-After 資訊，那麼客戶端應當以處理 500 回應的方式處理它。

**504 Gateway Timeout**
: 作為閘道器或者代理工作的伺服器嘗試執行請求時，未能及時從上游伺服器（URI 標識出的伺服器，例如 HTTP、FTP、LDAP）或者輔助伺服器（例如 DNS）收到回應。

　
: 注意：某些代理伺服器在 DNS 查詢逾時時會返回 400 或者 500 錯誤。

**505 HTTP Version Not Supported**
: 伺服器不支援，或者拒絕支援在請求中使用的 HTTP 版本。這暗示著伺服器不能或不願使用與客戶端相同的版本。回應中應當包含一個描述了為何版本不被支援以及伺服器支援哪些協定的實體。

**506 Variant Also Negotiates（RFC 2295）**
: 由《透明內容協商協定》（RFC 2295）擴充，代表伺服器存在內部組態錯誤，被請求的協商變元資源被組態為在透明內容協商中使用自己，因此在一個協商處理中不是一個合適的重點。

**507 Insufficient Storage（WebDAV；RFC 4918）**
: 伺服器無法儲存完成請求所必須的內容。這個狀況被認為是臨時的。

**508 Loop Detected （WebDAV；RFC 5842）**
: 伺服器在處理請求時陷入無窮迴圈。 （可代替 208 狀態碼）

**510 Not Extended（RFC 2774）**
: 取得資源所需要的策略並沒有被滿足。

**511 Network Authentication Required （RFC 6585）**
: 客戶端需要進行身分驗證才能獲得網路存取權限，旨在限制使用者群存取特定網路。（例如連接 WiFi 熱點時的強制網路門戶）

## 非官方狀態碼

**420 Enhance Your Calm**
: Twitter Search 與 Trends API 在客戶端被限速的情況下返回。

**444 No Response**
: Nginx 上 HTTP 伺服器擴展。伺服器不向客戶端返回任何資訊，並關閉連接（有助於阻止惡意軟體）。

**450 Blocked by Windows Parental Controls**
: 這是一個由 Windows 家庭控制（Microsoft）HTTP 阻止的 450 狀態代碼的範例，用於資訊和測試。

**494 Request Header Too Large**
: 在錯誤代碼 431 提出之前 Nginx 上使用的擴充 HTTP 代碼。

### IIS

微軟網際網路資訊服務 （Microsoft Internet Information Services）有時會使用額外的十進位子代碼來取得更多具體資訊，但是這些子代碼僅出現在回應有效內容和文件中，而不是代替實際的 HTTP 狀態代碼。

## 參見

* 超文字傳輸協定
* HTTP 頭欄位列表
* FTP 伺服器返回碼列表

## 參考文獻

## 外部連結

* Hypertext Transfer Protocol (HTTP) Status Code Registry（頁面存檔備份，存於網際網路檔案館）
* 微軟知識庫：MSKB943891: IIS 7.0、IIS 7.5 和 IIS 8.0 中的 HTTP 狀態代碼（頁面存檔備份，存於網際網路檔案館）
* httpstatus – 檢查網址重新導向路徑、請求標頭與 HTTP 狀態代碼（頁面存檔備份，存於網際網路檔案館）
* http-statuscode.com 所有的 HTTP 狀態代碼解釋