跳至內容

HTTP狀態碼

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
HTTP／HTTPS
版本
請求方法
報文主體
頭欄位
狀態碼
相關主題

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

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

所有HTTP響應狀態代碼分為五類。狀態代碼的第一位數字定義了響應的類別，而後兩位數字沒有分類作用。標準定義了五個類別：

  • 1xx 信息性響應 – 請求已接收，正在繼續處理
  • 2xx 成功 – 請求已成功接收、理解並接受
  • 3xx 重定向 – 需要採取進一步的措施以完成請求
  • 4xx 客戶端錯誤 – 請求包含語法錯誤或無法完成
  • 5xx 服務器錯誤 – 服務器未能完成明顯有效的請求

1xx消息

[編輯]

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

100 Continue
服務器已經接收到請求頭，並且客戶端應繼續發送請求主體（在需要發送身體的請求的情況下：例如，POST請求），或者如果請求已經完成，忽略這個響應。服務器必須在請求完成後向客戶端發送一個最終響應。要使服務器檢查請求的頭部，客戶端必須在其初始請求中發送Expect: 100-continue作為頭部，並在發送正文之前接收100 Continue狀態代碼。響應代碼417期望失敗表示請求不應繼續。[2]
101 Switching Protocols
服務器已經理解了客戶端的請求，並將通過Upgrade消息頭通知客戶端採用不同的協議來完成這個請求。在發送完這個響應最後的空行後，服務器將會切換到在Upgrade消息頭中定義的那些協議。[4]
只有在切換新的協議更有好處的時候才應該採取類似措施。例如，切換到新的HTTP版本（如HTTP/2）比舊版本更有優勢，或者切換到一個實時且同步的協議（如WebSocket）以傳送利用此類特性的資源。
102 Processing（WebDAV；RFC 2518）
WebDAV請求可能包含許多涉及文件操作的子請求，需要很長時間才能完成請求。該代碼表示服務器已經收到並正在處理請求，但無響應可用。[5]這樣可以防止客戶端超時，並假設請求丟失。
103 Early Hints (RFC 8297)
用來在最終的HTTP消息之前返回一些響應頭。

2xx成功

[編輯]

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

200 OK
請求已成功，請求所希望的響應頭或數據體將隨此響應返回。實際的響應將取決於所使用的請求方法。在GET請求中，響應將包含與請求的資源相對應的實體。在POST請求中，響應將包含描述或操作結果的實體。[6]
201 Created
請求已經被實現，而且有一個新的資源已經依據請求的需要而建立，且其URI已經隨Location頭信息返回。假如需要的資源無法及時建立的話，應當返回'202 Accepted'。[7]
202 Accepted
服務器已接受請求，但尚未處理。最終該請求可能會也可能不會被執行，並且可能在處理發生時被禁止。[8]
203 Non-Authoritative Information（自HTTP / 1.1起）
服務器是一個轉換代理服務器（transforming proxy，例如網絡加速器），以200 OK狀態碼為起源，但回應了原始響應的修改版本。[9][10]
204 No Content
服務器成功處理了請求，沒有返回任何內容。[11]在強制門戶功能中，Wi-Fi 設備連接到需要進行 Web 認證的 Wi-Fi 接入點時，通過訪問一個能生成 HTTP 204 響應的的網站，如果能正常收到 204 響應，則代表無需 Web 認證，否則會彈出網頁瀏覽器界面，顯示出 Web 網頁認證界面用於讓用戶認證登錄。
205 Reset Content
服務器成功處理了請求，但沒有返回任何內容。與204響應不同，此響應要求請求者重置文檔視圖。[12]
206 Partial Content（RFC 7233）
服務器已經成功處理了部分GET請求。類似於FlashGet或者迅雷這類的HTTP下載工具都是使用此類響應實現斷點續傳或者將一個大文檔分解為多個下載段同時下載。[13]
207 Multi-Status（WebDAV；RFC 4918）
代表之後的消息體將是一個XML消息，並且可能依照之前子請求數量的不同，包含一系列獨立的響應代碼。[14]
208 Already Reported （WebDAV；RFC 5842）
DAV綁定的成員已經在（多狀態）響應之前的部分被列舉，且未被再次包含。
226 IM Used （RFC 3229）
服務器已經滿足了對資源的請求，對實體請求的一個或多個實體操作的結果表示。[15]

3xx重定向

[編輯]

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

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

300 Multiple Choices
被請求的資源有一系列可供選擇的回饋信息，每個都有自己特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器能夠自行選擇一個首選的地址進行重定向。[17]
除非這是一個HEAD請求，否則該響應應當包括一個資源特性及地址的列表的實體，以便用戶或瀏覽器從中選擇最合適的重定向地址。這個實體的格式由Content-Type定義的格式所決定。瀏覽器可能根據響應的格式以及瀏覽器自身能力，自動作出最合適的選擇。當然，RFC 2616規範並沒有規定這樣的自動選擇該如何進行。
如果服務器本身已經有了首選的回饋選擇，那麼在Location中應當指明這個回饋的URI；瀏覽器可能會將這個Location值作為自動重定向的地址。此外，除非額外指定，否則這個響應也是可緩存的。
301 Moved Permanently
被請求的資源已永久移動到新位置，並且將來任何對此資源的引用都應該使用本響應返回的若干個URI之一。如果可能，擁有鏈接編輯功能的客戶端應當自動把請求的地址修改為從服務器反饋回來的地址。[18]除非額外指定，否則這個響應也是可緩存的。
新的永久性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，否則響應的實體中應當包含指向新的URI的超鏈接及簡短說明。
如果這不是一個GET或者HEAD請求，那麼瀏覽器禁止自動進行重定向，除非得到用戶的確認，因為請求的條件可能因此發生變化。
注意：對於某些使用HTTP/1.0協議的瀏覽器，當它們發送的POST請求得到了一個301響應的話，接下來的重定向請求將會變成GET方式。
302 Found
要求客戶端執行臨時重定向（原始描述短語為「Moved Temporarily」）。[19]由於這樣的重定向是臨時的，客戶端應當繼續向原有地址發送以後的請求。只有在Cache-Control或Expires中進行了指定的情況下，這個響應才是可緩存的。
新的臨時性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，否則響應的實體中應當包含指向新的URI的超鏈接及簡短說明。
如果這不是一個GET或者HEAD請求，那麼瀏覽器禁止自動進行重定向，除非得到用戶的確認，因為請求的條件可能因此發生變化。
注意：雖然RFC 1945和RFC 2068規範不允許客戶端在重定向時改變請求的方法，但是很多現存的瀏覽器將302響應視作為303響應，並且使用GET方式訪問在Location中規定的URI，而無視原先請求的方法。[20]因此狀態碼303和307被添加了進來，用以明確服務器期待客戶端進行何種反應。[21]
303 See Other
對應當前請求的響應可以在另一個URI上被找到，當響應於POST（或PUT / DELETE）接收到響應時，客戶端應該假定服務器已經收到數據，並且應該使用單獨的GET消息發出重定向。[22]這個方法的存在主要是為了允許由腳本激活的POST請求輸出重定向到一個新的資源。這個新的URI不是原始資源的替代引用。同時，303響應禁止被緩存。當然，第二個請求（重定向）可能被緩存。
新的URI應當在響應的Location域中返回。除非這是一個HEAD請求，否則響應的實體中應當包含指向新的URI的超鏈接及簡短說明。
注意：許多HTTP/1.1版以前的瀏覽器不能正確理解303狀態。如果需要考慮與這些瀏覽器之間的互動，302狀態碼應該可以勝任，因為大多數的瀏覽器處理302響應時的方式恰恰就是上述規範要求客戶端處理303響應時應當做的。
304 Not Modified
表示資源在由請求頭中的If-Modified-Since或If-None-Match參數指定的這一版本之後，未曾被修改。在這種情況下，由於客戶端仍然具有以前下載的副本，因此不需要重新傳輸資源。[23]
305 Use Proxy
被請求的資源必須通過指定的代理才能被訪問。Location域中將給出指定的代理所在的URI信息，接收者需要重複發送一個單獨的請求，通過這個代理才能訪問相應資源。只有原始服務器才能建立305響應。許多HTTP客戶端（像是Mozilla[24]）都沒有正確處理這種狀態代碼的響應，主要是出於安全考慮。[25]
注意：RFC 2068中沒有明確305響應是為了重定向一個單獨的請求，而且只能被原始服務器建立。忽視這些限制可能導致嚴重的安全後果。
306 Switch Proxy
在最新版的規範中，306狀態碼已經不再被使用。最初是指「後續請求應使用指定的代理」。[26]
307 Temporary Redirect
在這種情況下，請求應該與另一個URI重複，但後續的請求應仍使用原始的URI。 與302相反，當重新發出原始請求時，不允許更改請求方法。 例如，應該使用另一個POST請求來重複POST請求。[27]
308 Permanent Redirect (RFC 7538)
請求和所有將來的請求應該使用另一個URI重複。 307和308重複302和301的行為，但不允許HTTP方法更改。 例如，將表單提交給永久重定向的資源可能會順利進行。[28]

4xx客戶端錯誤

[編輯]

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

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

400 Bad Request
由於明顯的客戶端錯誤（例如，格式錯誤的請求語法，太大的大小，無效的請求消息或欺騙性路由請求），服務器不能或不會處理該請求。[30]
401 Unauthorized（RFC 7235）
參見：HTTP基本認證和HTTP摘要認證
類似於403 Forbidden，401語義即「未認證」，即用戶沒有必要的憑據。[31]該狀態碼表示當前請求需要用戶驗證。該響應必須包含一個適用於被請求資源的WWW-Authenticate信息頭用以詢問用戶信息。客戶端可以重複提交一個包含恰當的Authorization頭信息的請求。[32]如果當前請求已經包含了Authorization證書，那麼401響應代表着服務器驗證已經拒絕了那些證書。如果401響應包含了與前一個響應相同的身份驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那麼瀏覽器應當向用戶展示響應中包含的實體信息，因為這個實體信息中可能包含了相關診斷信息。
注意：當網站（通常是網站域名）禁止IP地址時，有些網站狀態碼顯示的401，表示該特定地址被拒絕訪問網站。
402 Payment Required
主條目：HTTP 402
該狀態碼是為了將來可能的需求而預留的。該狀態碼最初的意圖可能被用作某種形式的數字現金或在線支付方案的一部分，但幾乎沒有哪家服務商使用，而且這個狀態碼通常不被使用。如果特定開發人員已超過請求的每日限制，Google Developers API會使用此狀態碼。[33]
403 Forbidden
主條目：HTTP 403
服務器已經理解請求，但是拒絕執行它。與401響應不同的是，身份驗證並不能提供任何幫助，而且這個請求也不應該被重複提交。如果這不是一個HEAD請求，而且服務器希望能夠講清楚為何請求不能被執行，那麼就應該在實體內描述拒絕的原因。當然服務器也可以返回一個404響應，假如它不希望讓客戶端獲得任何信息。
404 Not Found
主條目：HTTP 404
請求失敗，請求所希望得到的資源未被在服務器上發現，但允許用戶的後續請求。[34]沒有信息能夠告訴用戶這個狀況到底是暫時的還是永久的。假如服務器知道情況的話，應當使用410狀態碼來告知舊資源因為某些內部的配置機制問題，已經永久的不可用，而且沒有任何可以跳轉的地址。404這個狀態碼被廣泛應用於當服務器不想揭示到底為何請求被拒絕或者沒有其他適合的響應可用的情況下。
405 Method Not Allowed
請求行中指定的請求方法不能被用於請求相應的資源。該響應必須返回一個Allow頭信息用以表示出當前資源能夠接受的請求方法的列表。例如，需要通過POST呈現數據的表單上的GET請求，或只讀資源上的PUT請求。
鑑於PUT，DELETE方法會對服務器上的資源進行寫操作，因而絕大部分的網頁服務器都不支持或者在默認配置下不允許上述請求方法，對於此類請求均會返回405錯誤。
406 Not Acceptable
參見：內容協商
請求的資源的內容特性無法滿足請求頭中的條件，因而無法生成響應實體，該請求不可接受。[35]
除非這是一個HEAD請求，否則該響應就應當返回一個包含可以讓用戶或者瀏覽器從中選擇最合適的實體特性以及地址列表的實體。實體的格式由Content-Type頭中定義的媒體類型決定。瀏覽器可以根據格式及自身能力自行作出最佳選擇。但是，規範中並沒有定義任何作出此類自動選擇的標準。
407 Proxy Authentication Required（RFC 2617）
與401響應類似，只不過客戶端必須在代理服務器上進行身份驗證。[36]代理服務器必須返回一個Proxy-Authenticate用以進行身份詢問。客戶端可以返回一個Proxy-Authorization信息頭用以驗證。
408 Request Timeout
請求超時。根據HTTP規範，客戶端沒有在服務器預備等待的時間內完成一個請求的發送，客戶端可以隨時再次提交這一請求而無需進行任何更改。[37]
409 Conflict
表示因為請求存在衝突無法處理該請求，例如多個同步更新之間的編輯衝突（英語：Edit conflict）。
410 Gone
表示所請求的資源不再可用。當資源被有意地刪除並且資源應被清除時，應該使用這個。在收到410狀態碼後，用戶應停止再次請求資源。[38]但大多數服務端不會使用此狀態碼，而是直接使用404狀態碼。
411 Length Required
服務器拒絕在沒有定義Content-Length頭的情況下接受請求。在添加了表明請求消息體長度的有效Content-Length頭之後，客戶端可以再次提交該請求。[39]
412 Precondition Failed（RFC 7232）
服務器在驗證在請求的頭字段中給出先決條件時，沒能滿足其中的一個或多個。[40]這個狀態碼允許客戶端在獲取資源時在請求的元信息（請求頭字段數據）中設置先決條件，以此避免該請求方法被應用到其希望的內容以外的資源上。
413 Request Entity Too Large（RFC 7231）
前稱「Request Entity Too Large」，表示服務器拒絕處理當前請求，因為該請求提交的實體數據大小超過了服務器願意或者能夠處理的範圍。[41]此種情況下，服務器可以關閉連接以免客戶端繼續發送此請求。
如果這個狀況是臨時的，服務器應當返回一個Retry-After的響應頭，以告知客戶端可以在多少時間以後重新嘗試。
414 Request-URI Too Long（RFC 7231）
前稱「Request-URI Too Long」，[42]表示請求的URI長度超過了服務器能夠解釋的長度，因此服務器拒絕對該請求提供服務。通常將太多數據的結果編碼為GET請求的查詢字符串，在這種情況下，應將其轉換為POST請求。[43]這比較少見，通常的情況包括：
  • 本應使用POST方法的表單提交變成了GET方法，導致查詢字符串過長。
  • 重定向URI「黑洞」，例如每次重定向把舊的URI作為新的URI的一部分，導致在若干次重定向後URI超長。
  • 客戶端正在嘗試利用某些服務器中存在的安全漏洞攻擊服務器。這類服務器使用固定長度的緩衝讀取或操作請求的URI，當GET後的參數超過某個數值後，可能會產生緩衝區溢出，導致任意代碼被執行[44]。沒有此類漏洞的服務器，應當返回414狀態碼。
415 Unsupported Media Type
對於當前請求的方法和所請求的資源，請求中提交的互聯網媒體類型並不是服務器中所支持的格式，因此請求被拒絕。例如，客戶端將圖像上傳格式為svg，但服務器要求圖像使用上傳格式為jpg。
416 Requested Range Not Satisfiable（RFC 7233）
前稱「Requested Range Not Satisfiable」。[45]客戶端已經要求文件的一部分（Byte serving（英語：Byte serving）），但服務器不能提供該部分。例如，如果客戶端要求文件的一部分超出文件尾端。[46]
417 Expectation Failed
在請求頭Expect中指定的預期內容無法被服務器滿足，或者這個服務器是一個代理服顯的證據證明在當前路由的下一個節點上，Expect的內容無法被滿足。[47]
418 I'm a teapot（RFC 2324，httpwg/http-core#43 （頁面存檔備份，存於網際網路檔案館））
本操作碼是在1998年作為IETF的傳統愚人節笑話, 在RFC 2324超文本咖啡壺控制協議中定義的，並不需要在真實的HTTP服務器中定義，同時也不是規範的HTTP狀態碼。當一個控制茶壺的HTCPCP收到BREW或POST指令要求其煮咖啡時應當回傳此錯誤。[48]這個HTTP狀態碼在某些網站（包括Google.com）與項目（如Node.js、ASP.NET和Go語言）中用作彩蛋。[49]
421 Misdirected Request （RFC 7540）
該請求針對的是無法產生響應的服務器（例如因為連接重用）。[50]
422 Unprocessable Entity（WebDAV；RFC 4918 ）
請求格式正確，但是由於含有語義錯誤，無法響應。[14]
423 Locked（WebDAV；RFC 4918）
當前資源被鎖定。[14]
424 Failed Dependency（WebDAV；RFC 4918）
由於之前的某個請求發生的錯誤，導致當前請求失敗，例如PROPPATCH。[14]
425 Too Early (RFC 8470)
服務器拒絕處理在Early Data中的請求，以規避可能的重放攻擊。[51]
426 Upgrade Required（RFC 2817）
客戶端應切換到Upgrade頭字段（英語：HTTP/1.1 Upgrade header）中給出的不同協議，如TLS/1.0。[14]
428 Precondition Required (RFC 6585)
原服務器要求該請求滿足一定條件。這是為了防止「未更新」問題，即客戶端讀取（GET）一個資源的狀態，更改它，並將它寫（PUT）回服務器，但這期間第三方已經在服務器上更改了該資源的狀態，因此導致了衝突。」[52]
429 Too Many Requests （RFC 6585）
用戶在給定的時間內發送了太多的請求。旨在用於網絡限速。[52]
431 Request Header Fields Too Large （RFC 6585）
服務器不願處理請求，因為一個或多個頭字段過大。[52]
440 Login Time-out
客戶端session逾時失效，需要重新登入。
451 Unavailable For Legal Reasons
主條目：HTTP 451
該訪問因法律的要求而被拒絕，由IETF在2015核准後新增加。[53][54][55]

5xx服務器錯誤

[編輯]

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

500 Internal Server Error
通用錯誤消息，服務器遇到了一個未曾預料的狀況，導致了它無法完成對請求的處理。沒有給出具體錯誤信息。[58]
501 Not Implemented
服務器不支持當前請求所需要的某個功能。當服務器無法識別請求的方法，並且無法支持其對任何資源的請求。[59]（例如，網絡服務API的新功能）
502 Bad Gateway
作為網關或者代理工作的服務器嘗試執行請求時，從上游服務器接收到無效的響應。[60]
503 Service Unavailable
由於臨時的服務器維護或者過載，服務器當前無法處理請求。這個狀況是暫時的，並且將在一段時間以後恢復。[61]如果能夠預計延遲時間，那麼響應中可以包含一個Retry-After頭用以標明這個延遲時間。如果沒有給出這個Retry-After信息，那麼客戶端應當以處理500響應的方式處理它。
504 Gateway Timeout
作為網關或者代理工作的服務器嘗試執行請求時，未能及時從上游服務器（URI標識出的服務器，例如HTTP、FTP、LDAP）或者輔助服務器（例如DNS）收到響應。[62]
注意：某些代理服務器在DNS查詢超時時會返回400或者500錯誤。
505 HTTP Version Not Supported
服務器不支持，或者拒絕支持在請求中使用的HTTP版本。[63]這暗示着服務器不能或不願使用與客戶端相同的版本。響應中應當包含一個描述了為何版本不被支持以及服務器支持哪些協議的實體。
506 Variant Also Negotiates（RFC 2295）
由《透明內容協商協議》（RFC 2295）擴展，代表服務器存在內部配置錯誤，[64]被請求的協商變元資源被配置為在透明內容協商中使用自己，因此在一個協商處理中不是一個合適的重點。
507 Insufficient Storage（WebDAV；RFC 4918）
服務器無法存儲完成請求所必須的內容。這個狀況被認為是臨時的。[14]
508 Loop Detected （WebDAV；RFC 5842）
服務器在處理請求時陷入死循環。 （可代替 208狀態碼）
510 Not Extended（RFC 2774）
獲取資源所需要的策略並沒有被滿足。[65]
511 Network Authentication Required （RFC 6585）
客戶端需要進行身份驗證才能獲得網絡訪問權限，旨在限制用戶群訪問特定網絡。（例如連接WiFi熱點時的強制網絡門戶）[52]

非官方狀態碼

[編輯]
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）有時會使用額外的十進制子代碼來獲取更多具體信息，[66]但是這些子代碼僅出現在響應有效內容和文檔中，而不是代替實際的HTTP狀態代碼。

參見

[編輯]

參考文獻

[編輯]
  1. ^ Hypertext Transfer Protocol ---HTTP/1.1. IETF. [2015-10-16]. （原始內容存檔於2011-03-07）. 
  2. ^ 2.0 2.1 2.2 2.3 Hypertext Transfer Protocol (HTTP) Status Code Registry. Iana.org. [2015-01-08]. （原始內容存檔於2011-12-11）. 
  3. ^ 10 Status Code Definitions. W3. [2015-10-16]. （原始內容存檔於2010-03-16）. 
  4. ^ 101. httpstatus. [2015-10-16]. （原始內容存檔於2015-10-30）. 
  5. ^ Goland, Yaronn; Whitehead, Jim; Faizi, Asad; Carter, Steve R.; Jensen, Del. HTTP Extensions for Distributed Authoring – WEBDAV. IETF. February 1999 [2009-10-24]. RFC 2518. 
  6. ^ 200 OK. Hypertext Transfer Protocol -- HTTP/1.1. IETF. June 1999: sec. 10.2.1 [2016-08-30]. RFC 2616. 
  7. ^ Stewart, Mark; djna. Create request with POST, which response codes 200 or 201 and content. Stack Overflow. [2015-10-16]. （原始內容存檔於2016-10-11）. 
  8. ^ 202. httpstatus. [2015-10-16]. （原始內容存檔於2015-10-19）. 
  9. ^ RFC 7231, Section 6.3.4.. （原始內容存檔於2017-05-25）. 
  10. ^ RFC 7230, Section 5.7.2.. [2017-05-12]. （原始內容存檔於2016-02-03）. 
  11. ^ Simmance, Chris. Server Response Codes And What They Mean. koozai. [2015-10-16]. （原始內容存檔於2015-09-26）. 
  12. ^ ikitommi; Deraen. metosin/ring-http-response. GitHub. [2015-10-16]. （原始內容存檔於2019-02-16）. 
  13. ^ diff --git a/linkchecker.module b/linkchecker.module. Drupal. [2015-10-16]. （原始內容存檔於2016-03-04）. 
  14. ^ 14.0 14.1 14.2 14.3 14.4 14.5 Dusseault, Lisa. HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). IETF. June 2007 [2009-10-24]. RFC 4918. 
  15. ^ Delta encoding in HTTP. IETF. January 2002 [2011-02-25]. RFC 3229. 
  16. ^ Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. IETF. [2016-02-13]. （原始內容存檔於2017-05-25）. 
  17. ^ 300. httpstatus. [2015-10-16]. （原始內容存檔於2015-10-17）. 
  18. ^ 301. httpstatus. [2015-10-16]. （原始內容存檔於2015-10-27）. 
  19. ^ Berners-Lee, Tim; Fielding, Roy T.; Nielsen, Henrik Frystyk. Hypertext Transfer Protocol – HTTP/1.0. IETF. May 1996 [2009-10-24]. RFC 1945. 
  20. ^ Reference of method redirect_to in Ruby Web Framework "Ruby on Rails". It states: The redirection happens as a "302 Moved" header unless otherwise specified.. [2012-06-30]. （原始內容存檔於2012-07-05）. 
  21. ^ Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, Section 6.4. IETF. [2014-06-12]. （原始內容存檔於2017-05-25）. 
  22. ^ 303. httpstatus. [2015-10-16]. （原始內容存檔於2015-10-22）. 
  23. ^ Brown, Kevin; CRS... getting 304 response even with django-cors-headers. Stack Overflow. [2015-10-16]. （原始內容存檔於2015-11-10）. 
  24. ^ Mozilla Bugzilla Bug 187996: Strange behavior on 305 redirect. 2003-03-03 [2009-05-21]. （原始內容存檔於2014-04-21）. 
  25. ^ Mozilla Bugzilla Bug 187996: Strange behavior on 305 redirect, comment 13. 2003-03-03 [2009-05-21]. （原始內容存檔於2014-04-21）. 
  26. ^ Cohen, Josh. HTTP/1.1 305 and 306 Response Codes. HTTP Working Group. [2017-05-12]. （原始內容存檔於2014-09-08）. 
  27. ^ Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, Section 6.4.7 307 Temporary Redirect. IETF. 2014 [2014-09-20]. （原始內容存檔於2017-05-25）. 
  28. ^ The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). Internet Engineering Task Force. April 2015 [2015-04-06]. （原始內容存檔於2015-04-16）. 
  29. ^ E Explanation of Failure Codes. Oracle. [2015-10-16]. （原始內容存檔於2015-02-16）. 
  30. ^ RFC7231 on code 400. Tools.ietf.org. [2015-01-08]. （原始內容存檔於2017-05-25）. 
  31. ^ RFC7235 on code 401. Tools.ietf.org. [2015-02-08]. （原始內容存檔於2015-02-07）. 
  32. ^ 401. httpstatus. [2015-10-16]. （原始內容存檔於2015-10-17）. 
  33. ^ Google API Standard Error Responses. Google. 2015 [2015-09-24]. （原始內容存檔於2017-05-25）. 
  34. ^ Introduction. QAS. [2015-10-16]. （原始內容存檔於2015-11-23）. 
  35. ^ Singh, Prabhat; user1740567. Spring 3.x JSON status 406 "characteristics not acceptable according to the request "accept" headers ()". Stack Overflow. [2015-10-16]. （原始內容存檔於2016-10-11）. 
  36. ^ 407. httpstatus. [2015-10-16]. （原始內容存檔於2015-10-11）. 
  37. ^ 408. httpstatus. [2015-10-16]. （原始內容存檔於2015-10-31）. 
  38. ^ Does Google treat 404 and 410 status codes differently? (Youtube). Google. 2014 [2015-02-04]. （原始內容存檔於2015-01-08）. 
  39. ^ List of HTTP status codes. Google Books. [2015-10-16]. （原始內容存檔於2015-11-23）. 
  40. ^ Kowser; Patel, Amit. REST response code for invalid data. Stack Overflow. [2015-10-16]. （原始內容存檔於2016-10-11）. 
  41. ^ RFC2616 on status 413. Tools.ietf.org. [2015-11-11]. （原始內容存檔於2011-03-07）. 
  42. ^ RFC2616 on status 414. Tools.ietf.org. [2015-11-11]. （原始內容存檔於2011-03-07）. 
  43. ^ user27828. GET Request - Why is my URI so long?. Stack Overflow. [2015-10-16]. （原始內容存檔於2016-10-11）. 
  44. ^ HTTP Get存在缓冲溢出漏洞. [2008-05-05]. （原始內容存檔於2009-03-18）. 
  45. ^ RFC2616 on status 416. Tools.ietf.org. [2015-11-11]. （原始內容存檔於2011-03-07）. 
  46. ^ Sigler, Chris. 416 Requested Range Not Satisfiable. GetStatusCode. [2015-10-16]. （原始內容存檔於2015-10-22）. 
  47. ^ TheDeadLike. HTTP/1.1 Status Codes 400 and 417, cannot choose which. serverFault. [2015-10-16]. （原始內容存檔於2015-10-10）. 
  48. ^ Larry Masinter. Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). 1998-04-01. RFC 2324. 
  49. ^ Barry Schwartz. New Google Easter Egg For SEO Geeks: Server Status 418, I'm A Teapot. Search Engine Land. 2014-08-26 [2017-05-12]. （原始內容存檔於2015-11-15）. 
  50. ^ Hypertext Transfer Protocol version 2. March 2015 [2015-04-25]. （原始內容存檔於2015-04-25）. 
  51. ^ The 425 (Too Early) Status Code. [2019-06-21]. （原始內容存檔於2019-10-17）. 
  52. ^ 52.0 52.1 52.2 52.3 Nottingham, M.; Fielding, R. RFC 6585 – Additional HTTP Status Codes. Request for Comments. Internet Engineering Task Force. April 2012 [2012-05-01]. （原始內容存檔於2012-05-04）. 
  53. ^ Bray, T. An HTTP Status Code to Report Legal Obstacles. ietf.org. February 2016 [2015-03-07]. （原始內容存檔於2016-03-04）. 
  54. ^ Brian Chen. IESG 批准全新 HTTP 狀態碼「451」. 科技新報. 2015-12-21 [2015-12-22]. （原始內容存檔於2015-12-25） （中文（繁體））. 
  55. ^ 林妍溱. 未來上網碰到錯誤代碼451，你瀏覽的網頁被封鎖了!. iThome. 2015-12-22 [2015-12-22]. （原始內容存檔於2015-12-23）. 
  56. ^ Server Error Codes. CSGNetwork.com. [2015-10-16]. （原始內容存檔於2015-10-08）. 
  57. ^ mrGott. HTTP Status Codes To Handle Errors In Your API. mrGott. [2015-10-16]. （原始內容存檔於2015-09-30）. 
  58. ^ Fisher, Tim. 500 Internal Server Error. Lifewire. [2017-02-22]. （原始內容存檔於2017-02-23）. 
  59. ^ HTTP Error 501 Not implemented. Check Up Down. [2017-02-22]. （原始內容存檔於2017-05-12）. 
  60. ^ Fisher, Tim. 502 Bad Gateway. Lifewire. [2017-02-22]. （原始內容存檔於2017-02-23）. 
  61. ^ alex. What is the correct HTTP status code to send when a site is down for maintenance?. Stack Overflow. [2015-10-16]. （原始內容存檔於2016-10-11）. 
  62. ^ HTTP Error 504 Gateway timeout. Check Up Down. [2015-10-16]. （原始內容存檔於2015-09-20）. 
  63. ^ HTTP Error 505 - HTTP version not supported. Check Up Down. [2015-10-16]. （原始內容存檔於2015-09-24）. 
  64. ^ Holtman, Koen; Mutz, Andrew H.. Transparent Content Negotiation in HTTP. IETF. March 1998 [2009-10-24]. RFC 2295. 
  65. ^ Nielsen, Henrik Frystyk; Leach, Paul; Lawrence, Scott. An HTTP Extension Framework. IETF. February 2000 [2009-10-24]. RFC 2774. 
  66. ^ The HTTP status codes in IIS 7.0. Microsoft. 2009-07-14 [2009-04-01]. （原始內容存檔於2009-04-09）. 

外部連結

[編輯]
維基共享資源上的相關多媒體資源：HTTP狀態碼
取自「https://wikicn.playgoteam.workers.dev/w/index.php?title=HTTP状态码&oldid=84508612」