HTTP狀態碼

時間 2019-11-07

標籤 http 狀態欄目 HTTP/TCP 简体版

原文原文鏈接

HTTP狀態碼

轉自維基百科

https://zh.wikipedia.org/wiki/HTTP%E7%8A%B6%E6%80%81%E7%A0%81

HTTP狀態碼（英語：HTTP Status Code）是用以表示網頁服務器超文本傳輸協議響應狀態的3位數字代碼。它由 RFC 2616 規範定義的，並獲得 RFC 251八、RFC 281七、RFC 229五、RFC 2774 與 RFC 4918 等規範擴展。全部狀態碼的第一個數字表明瞭響應的五種狀態之一。所示的消息短語是典型的，可是能夠提供任何可讀取的替代方案。除非另有說明，狀態碼是HTTP / 1.1標準（RFC 7231）的一部分。瀏覽器

HTTP狀態碼的官方註冊表由互聯網號碼分配局（Internet Assigned Numbers Authority）維護。緩存

微軟互聯網信息服務（Microsoft Internet Information Services）有時會使用額外的十進制子代碼來獲取更多具體信息，[3]可是這些子代碼僅出如今響應有效內容和文檔中，而不是代替實際的HTTP狀態代碼。安全

1xx消息

這一類型的狀態碼，表明請求已被接受，須要繼續處理。這類響應是臨時響應，只包含狀態行和某些可選的響應頭信息，並以空行結束。因爲HTTP/1.0協議中沒有定義任何1xx狀態碼，因此除非在某些試驗條件下，服務器禁止向此類客戶端發送1xx響應。這些狀態碼錶明的響應都是信息性的，標示客戶應該採起的其餘行動。服務器

100 Continue

服務器已經接收到請求頭，而且客戶端應繼續發送請求主體（在須要發送身體的請求的狀況下：例如，POST請求），或者若是請求已經完成，忽略這個響應。服務器必須在請求完成後向客戶端發送一個最終響應。要使服務器檢查請求的頭部，客戶端必須在其初始請求中發送Expect: 100-continue做爲頭部，並在發送正文以前接收100 Continue狀態代碼。響應代碼417指望失敗表示請求不該繼續。網絡

101 Switching Protocols

服務器已經理解了客戶端的請求，並將經過Upgrade消息頭通知客戶端採用不一樣的協議來完成這個請求。在發送完這個響應最後的空行後，服務器將會切換到在Upgrade消息頭中定義的那些協議。
只有在切換新的協議更有好處的時候才應該採起相似措施。例如，切換到新的HTTP版本（如HTTP/2）比舊版本更有優點，或者切換到一個實時且同步的協議（如WebSocket）以傳送利用此類特性的資源。ide

102 Processing（WebDAV；RFC 2518）

WebDAV請求可能包含許多涉及文件操做的子請求，須要很長時間才能完成請求。該代碼表示服務器已經收到並正在處理請求，但無響應可用。[6]這樣能夠防止客戶端超時，並假設請求丟失。svg

2xx成功

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

200 OK

請求已成功，請求所但願的響應頭或數據體將隨此響應返回。實際的響應將取決於所使用的請求方法。在GET請求中，響應將包含與請求的資源相對應的實體。在POST請求中，響應將包含描述或操做結果的實體。oop

201 Created

請求已經被實現，並且有一個新的資源已經依據請求的須要而創建，且其URI已經隨Location頭信息返回。假如須要的資源沒法及時建立的話，應當返回'202 Accepted'。[8]測試

202 Accepted

服務器已接受請求，但還沒有處理。最終該請求可能會也可能不會被執行，而且可能在處理髮生時被禁止。[9]

203 Non-Authoritative Information（自HTTP / 1.1起）

服務器是一個轉換代理服務器（transforming proxy，例如網絡加速器），以200 OK狀態碼爲起源，但迴應了原始響應的修改版本。[10][11]

204 No Content

服務器成功處理了請求，沒有返回任何內容。[12]

205 Reset Content

服務器成功處理了請求，但沒有返回任何內容。與204響應不一樣，此響應要求請求者重置文檔視圖。[13]

206 Partial Content（RFC 7233）

服務器已經成功處理了部分GET請求。相似於FlashGet或者迅雷這類的HTTP 下載工具都是使用此類響應實現斷點續傳或者將一個大文檔分解爲多個下載段同時下載。[14]

207 Multi-Status（WebDAV；RFC 4918）

表明以後的消息體將是一個XML消息，而且可能依照以前子請求數量的不一樣，包含一系列獨立的響應代碼。[15]

208 Already Reported （WebDAV；RFC 5842）

DAV綁定的成員已經在（多狀態）響應以前的部分被列舉，且未被再次包含。

226 IM Used （RFC 3229）

服務器已經知足了對資源的請求，對實體請求的一個或多個實體操做的結果表示。[16]

3xx重定向

這類狀態碼錶明須要客戶端採起進一步的操做才能完成請求。一般，這些狀態碼用來重定向，後續的請求地址（重定向目標）在本次響應的Location域中指明。[2]

當且僅當後續的請求所使用的方法是GET或者HEAD時，用戶瀏覽器才能夠在沒有用戶介入的狀況下自動提交所須要的後續請求。客戶端應當自動監測無限循環重定向（例如：A→B→C→……→A或A→A），由於這會致使服務器和客戶端大量沒必要要的資源消耗。按照HTTP/1.0版規範的建議，瀏覽器不該自動訪問超過5次的重定向。[17]

300 Multiple Choices

被請求的資源有一系列可供選擇的回饋信息，每一個都有本身特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器可以自行選擇一個首選的地址進行重定向。[18]
除非這是一個HEAD請求，不然該響應應當包括一個資源特性及地址的列表的實體，以便用戶或瀏覽器從中選擇最合適的重定向地址。這個實體的格式由Content-Type定義的格式所決定。瀏覽器可能根據響應的格式以及瀏覽器自身能力，自動做出最合適的選擇。固然，RFC 2616規範並無規定這樣的自動選擇該如何進行。
若是服務器自己已經有了首選的回饋選擇，那麼在Location中應當指明這個回饋的URI；瀏覽器可能會將這個Location值做爲自動重定向的地址。此外，除非額外指定，不然這個響應也是可緩存的。

301 Moved Permanently

被請求的資源已永久移動到新位置，而且未來任何對此資源的引用都應該使用本響應返回的若干個URI之一。若是可能，擁有連接編輯功能的客戶端應當自動把請求的地址修改成從服務器反饋回來的地址。[19]除非額外指定，不然這個響應也是可緩存的。
新的永久性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。
若是這不是一個GET或者HEAD請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。
注意：對於某些使用HTTP/1.0協議的瀏覽器，當它們發送的POST請求獲得了一個301響應的話，接下來的重定向請求將會變成GET方式。

302 Found

要求客戶端執行臨時重定向（原始描述短語爲「Moved Temporarily」）。[20]因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。
新的臨時性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。
若是這不是一個GET或者HEAD請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。
注意：雖然RFC 1945和RFC 2068規範不容許客戶端在重定向時改變請求的方法，可是不少現存的瀏覽器將302響應視做爲303響應，而且使用GET方式訪問在Location中規定的URI，而無視原先請求的方法。[21]所以狀態碼303和307被添加了進來，用以明確服務器期待客戶端進行何種反應。[22]

303 See Other

對應當前請求的響應能夠在另外一個URI上被找到，當響應於POST（或PUT / DELETE）接收到響應時，客戶端應該假定服務器已經收到數據，而且應該使用單獨的GET消息發出重定向。[23]這個方法的存在主要是爲了容許由腳本激活的POST請求輸出重定向到一個新的資源。這個新的URI不是原始資源的替代引用。同時，303響應禁止被緩存。固然，第二個請求（重定向）可能被緩存。
新的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。
注意：許多HTTP/1.1版之前的瀏覽器不能正確理解303狀態。若是須要考慮與這些瀏覽器之間的互動，302狀態碼應該能夠勝任，由於大多數的瀏覽器處理302響應時的方式偏偏就是上述規範要求客戶端處理303響應時應當作的。

304 Not Modified

表示資源在由請求頭中的If-Modified-Since或If-None-Match參數指定的這一版本以後，不曾被修改。在這種狀況下，因爲客戶端仍然具備之前下載的副本，所以不須要從新傳輸資源。[24]

305 Use Proxy

被請求的資源必須經過指定的代理才能被訪問。Location域中將給出指定的代理所在的URI信息，接收者須要重複發送一個單獨的請求，經過這個代理才能訪問相應資源。只有原始服務器才能建立305響應。許多HTTP客戶端（像是Mozilla[25]和Internet Explorer）都沒有正確處理這種狀態代碼的響應，主要是出於安全考慮。[26]
注意：RFC 2068中沒有明確305響應是爲了重定向一個單獨的請求，並且只能被原始服務器創建。忽視這些限制可能致使嚴重的安全後果。

306 Switch Proxy

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

307 Temporary Redirect

在這種狀況下，請求應該與另外一個URI重複，但後續的請求應仍使用原始的URI。與302相反，當從新發出原始請求時，不容許更改請求方法。例如，應該使用另外一個POST請求來重複POST請求。[28]

308 Permanent Redirect (RFC 7538)

請求和全部未來的請求應該使用另外一個URI重複。 307和308重複302和301的行爲，但不容許HTTP方法更改。例如，將表單提交給永久重定向的資源可能會順利進行。[29]

4xx客戶端錯誤

這類的狀態碼錶明瞭客戶端看起來可能發生了錯誤，妨礙了服務器的處理。除非響應的是一個HEAD請求，不然服務器就應該返回一個解釋當前錯誤情況的實體，以及這是臨時的仍是永久性的情況。這些狀態碼適用於任何請求方法。瀏覽器應當向用戶顯示任何包含在此類錯誤響應中的實體內容。[30]

若是錯誤發生時客戶端正在傳送數據，那麼使用TCP的服務器實現應當仔細確保在關閉客戶端與服務器之間的鏈接以前，客戶端已經收到了包含錯誤信息的數據包。若是客戶端在收到錯誤信息後繼續向服務器發送數據，服務器的TCP棧將向客戶端發送一個重置數據包，以清除該客戶端全部還未識別的輸入緩衝，以避免這些數據被服務器上的應用程序讀取並干擾後者。

400 Bad Request

因爲明顯的客戶端錯誤（例如，格式錯誤的請求語法，太大的大小，無效的請求消息或欺騙性路由請求），服務器不能或不會處理該請求。[31]

401 Unauthorized（RFC 7235）

參見：HTTP基本認證、HTTP摘要認證
相似於403 Forbidden，401語義即「未認證」，即用戶沒有必要的憑據。[32]該狀態碼錶示當前請求須要用戶驗證。該響應必須包含一個適用於被請求資源的WWW-Authenticate信息頭用以詢問用戶信息。客戶端能夠重複提交一個包含恰當的Authorization頭信息的請求。[33]若是當前請求已經包含了Authorization證書，那麼401響應表明着服務器驗證已經拒絕了那些證書。若是401響應包含了與前一個響應相同的身份驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那麼瀏覽器應當向用戶展現響應中包含的實體信息，由於這個實體信息中可能包含了相關診斷信息。
注意：當網站（一般是網站域名）禁止IP地址時，有些網站狀態碼顯示的401，表示該特定地址被拒絕訪問網站。

402 Payment Required

該狀態碼是爲了未來可能的需求而預留的。該狀態碼最初的意圖可能被用做某種形式的數字現金或在線支付方案的一部分，但幾乎沒有哪家服務商使用，並且這個狀態碼一般不被使用。若是特定開發人員已超過請求的每日限制，Google Developers API會使用此狀態碼。[34]

403 Forbidden

主條目：HTTP 403
服務器已經理解請求，可是拒絕執行它。與401響應不一樣的是，身份驗證並不能提供任何幫助，並且這個請求也不該該被重複提交。若是這不是一個HEAD請求，並且服務器但願可以講清楚爲什麼請求不能被執行，那麼就應該在實體內描述拒絕的緣由。固然服務器也能夠返回一個404響應，假如它不但願讓客戶端得到任何信息。

404 Not Found

主條目：HTTP 404
請求失敗，請求所但願獲得的資源未被在服務器上發現，但容許用戶的後續請求。[35]沒有信息可以告訴用戶這個情況究竟是暫時的仍是永久的。假如服務器知道狀況的話，應當使用410狀態碼來告知舊資源由於某些內部的配置機制問題，已經永久的不可用，並且沒有任何能夠跳轉的地址。404這個狀態碼被普遍應用於當服務器不想揭示到底爲什麼請求被拒絕或者沒有其餘適合的響應可用的狀況下。

405 Method Not Allowed

請求行中指定的請求方法不能被用於請求相應的資源。該響應必須返回一個Allow頭信息用以表示出當前資源可以接受的請求方法的列表。例如，須要經過POST呈現數據的表單上的GET請求，或只讀資源上的PUT請求。
鑑於PUT，DELETE方法會對服務器上的資源進行寫操做，於是絕大部分的網頁服務器都不支持或者在默認配置下不容許上述請求方法，對於此類請求均會返回405錯誤。

406 Not Acceptable

參見：內容協商
請求的資源的內容特性沒法知足請求頭中的條件，於是沒法生成響應實體，該請求不可接受。[36]
除非這是一個HEAD請求，不然該響應就應當返回一個包含可讓用戶或者瀏覽器從中選擇最合適的實體特性以及地址欄表的實體。實體的格式由Content-Type頭中定義的媒體類型決定。瀏覽器能夠根據格式及自身能力自行做出最佳選擇。可是，規範中並無定義任何做出此類自動選擇的標準。

407 Proxy Authentication Required（RFC 2617）

與401響應相似，只不過客戶端必須在代理服務器上進行身份驗證。[37]代理服務器必須返回一個Proxy-Authenticate用以進行身份詢問。客戶端能夠返回一個Proxy-Authorization信息頭用以驗證。

408 Request Timeout

請求超時。根據HTTP規範，客戶端沒有在服務器預備等待的時間內完成一個請求的發送，客戶端能夠隨時再次提交這一請求而無需進行任何更改。[38]

409 Conflict

表示由於請求存在衝突沒法處理該請求，例如多個同步更新之間的編輯衝突。

410 Gone

表示所請求的資源再也不可用，將再也不可用。當資源被有意地刪除而且資源應被清除時，應該使用這個。在收到410狀態碼後，用戶應中止再次請求資源。[39]但大多數服務端不會使用此狀態碼，而是直接使用404狀態碼。

411 Length Required

服務器拒絕在沒有定義Content-Length頭的狀況下接受請求。在添加了代表請求消息體長度的有效Content-Length頭以後，客戶端能夠再次提交該請求。[40]

412 Precondition Failed（RFC 7232）

服務器在驗證在請求的頭字段中給出先決條件時，沒能知足其中的一個或多個。[41]這個狀態碼容許客戶端在獲取資源時在請求的元信息（請求頭字段數據）中設置先決條件，以此避免該請求方法被應用到其但願的內容之外的資源上。

413 Request Entity Too Large（RFC 7231）

前稱「Request Entity Too Large」，表示服務器拒絕處理當前請求，由於該請求提交的實體數據大小超過了服務器願意或者可以處理的範圍。[42]此種狀況下，服務器能夠關閉鏈接以避免客戶端繼續發送此請求。
若是這個情況是臨時的，服務器應當返回一個Retry-After的響應頭，以告知客戶端能夠在多少時間之後從新嘗試。

414 Request-URI Too Long（RFC 7231）

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

415 Unsupported Media Type

對於當前請求的方法和所請求的資源，請求中提交的互聯網媒體類型並非服務器中所支持的格式，所以請求被拒絕。例如，客戶端將圖像上傳格式爲svg，但服務器要求圖像使用上傳格式爲jpg。

416 Requested Range Not Satisfiable（RFC 7233）

前稱「Requested Range Not Satisfiable」。[46]客戶端已經要求文件的一部分（Byte serving），但服務器不能提供該部分。例如，若是客戶端要求文件的一部分超出文件尾端。[47]
417 Expectation Failed
在請求頭Expect中指定的預期內容沒法被服務器知足，或者這個服務器是一個代理服顯的證據證實在當前路由的下一個節點上，Expect的內容沒法被知足。[48]

418 I'm a teapot（RFC 2324）

本操做碼是在1998年做爲IETF的傳統愚人節笑話, 在RFC 2324超文本咖啡壺控制協議'中定義的，並不須要在真實的HTTP服務器中定義。當一個控制茶壺的HTCPCP收到BREW或POST指令要求其煮咖啡時應當回傳此錯誤。[49]這個HTTP狀態碼在某些網站（包括Google.com）與項目（如Node.js、ASP.NET和Go語言）中用做彩蛋。[50]

420 Enhance Your Caim

Twitter Search與Trends API在客戶端被限速的狀況下返回。

421 Misdirected Request （RFC 7540）

該請求針對的是沒法產生響應的服務器（例如由於鏈接重用）。[51]

422 Unprocessable Entity（WebDAV；RFC 4918 ）

請求格式正確，可是因爲含有語義錯誤，沒法響應。[15]

423 Locked（WebDAV；RFC 4918）

當前資源被鎖定。[15]

424 Failed Dependency（WebDAV；RFC 4918）

因爲以前的某個請求發生的錯誤，致使當前請求失敗，例如PROPPATCH。[15]

425 Unordered Collection

在WebDAV Advanced Collections Protocol中定義，但Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol中並不存在。

426 Upgrade Required（RFC 2817）

客戶端應當切換到TLS/1.0，並在HTTP/1.1 Upgrade header中給出。[15]

428 Precondition Required (RFC 6585)

原服務器要求該請求知足必定條件。這是爲了防止「‘未更新’問題，即客戶端讀取（GET）一個資源的狀態，更改它，並將它寫（PUT）回服務器，但這期間第三方已經在服務器上更改了該資源的狀態，所以致使了衝突。」[52]

429 Too Many Requests （RFC 6585）

用戶在給定的時間內發送了太多的請求。旨在用於網絡限速。[52]

431 Request Header Fields Too Large （RFC 6585）

服務器不肯處理請求，由於一個或多個頭字段過大。[52]

444 No Response

Nginx上HTTP服務器擴展。服務器不向客戶端返回任何信息，並關閉鏈接（有助於阻止惡意軟件）。

450 Blocked by Windows Parental Controls

這是一個由Windows家庭控制（Microsoft）HTTP阻止的450狀態代碼的示例，用於信息和測試。

451 Unavailable For Legal Reasons

主條目：HTTP 451
該訪問因法律的要求而被拒絕，由IETF在2015覈准後新增長。[53][54][55]

494 Request Header Too Large

在錯誤代碼431提出以前Nginx上使用的擴展HTTP代碼。

5xx服務器錯誤

表示服務器沒法完成明顯有效的請求。[56]這類狀態碼錶明瞭服務器在處理請求的過程當中有錯誤或者異常狀態發生，也有多是服務器意識到以當前的軟硬件資源沒法完成對請求的處理。除非這是一個HEAD請求，不然服務器應當包含一個解釋當前錯誤狀態以及這個情況是臨時的仍是永久的解釋信息實體。瀏覽器應當向用戶展現任何在當前響應中被包含的實體。這些狀態碼適用於任何響應方法。[57]