HTTP五大類標準狀態碼一網打盡
【概述】
狀態碼是服務器在響應客戶端向請求時發出的結果碼。
狀態碼的第一個數字指定了五個標準的響應類別中的一個。
所展示的消息短語是經典通用的，人類可讀的。
互聯網號碼分配機構(IANA)維護著HTTP狀態碼的官方注冊表。
所有HTTP響應的狀態碼都被分為五個分類。
狀態碼的第一位數字定義了響應的類別，而后兩位數字沒有任何分類或歸類的作用。
五個類別:
l??1xx --------------------信息性響應--收到請求，繼續處理中
l??2xx成功-------------成功地收到，并處理了請求；
l??3xx重新定向-------需要采取進一步行動才能完成請求
l??4xx客戶端錯誤----請求包含錯誤的語法或無法滿足的請求
l??5xx服務器錯誤----服務器未能完成一個有效的請求。
【1xx?信息性響應】
信息性響應表示已收到并理解請求。
它是在請求處理過程中臨時發出的。
它提醒客戶機等待最終的響應。
該消息僅由狀態行和可選的頭字段組成，并以空行結束。
由于HTTP/1.0標準沒有定義任何1xx狀態碼，所以服務器不能向符合HTTP/1.0標準的客戶端發送1xx響應。
100?繼續
如果服務器已經收到了請求頭，客戶端應該繼續發送請求正文（如需要發送正文的請求的話，例如POST請求）。
在請求因不合適的標題而被拒絕后，再向服務器請求正文是沒有意義的。
為了讓服務器先檢查請求頭，客戶端必須在發送body之前，在初始請求中發送Expect: 100-continue作為請求頭，并在響應中收到一個100 Continue狀態碼。
如果客戶端收到一個錯誤代碼，如403（Forbidden）或405（Method Not Allowed），那么它不應該再發送請求正文。
響應417 Expectation Failed表示請求應該在沒有Expect頭的情況下重復請求，因為它表示服務器不支持Expect頭（例如，HTTP/1.0服務器就是這種情況）。
101切換協議
請求者要求服務器切換協議，服務器也同意切換協議。
102處理（WebDAV，RFC 2518）
一個WebDAV請求可能包含許多涉及文件操作的子請求，需要很長時間才能完成請求。這個代碼表示服務器已經收到并正在處理請求，但還沒有響應，這可以防止客戶端超時從而假設請求丟失。
103早期提示(RFC 8297)
用于在最終的HTTP報文之前返回一些響應頭。
【2xx成功】
這類狀態碼表示客戶的請求已被接收、理解和處理。
200 OK
成功的HTTP請求的標準響應。
實際的響應將取決于所使用的請求方法。在GET請求中，響應將包含一個與請求資源相對應的實體。
在POST請求中，響應將包含一個描述或包含操作結果的實體。
201?已創建
該請求已被處理，從而創建了新的資源。
202?已接受
請求已被接受并處理，但處理工作尚未完成。
該請求最終可能會被處理完成，也可能不會，這取決于處理時是否被駁回。
203非授權信息（自HTTP/1.1以來）
服務器是一個轉換代理（如Web加速器），它收到了200 OK，但返回的是原始響應的修改版本。
204?無內容
服務器成功處理了該請求，沒有返回任何內容。
205內容重置
服務器成功處理了請求，但沒有返回任何內容。與204響應不同的是，這個響應要求請求者重置文檔視圖。
206部分內容（RFC 7233）
由于客戶端發送的范圍頭，服務器只傳遞了部分資源（字節服務）。
范圍報頭被HTTP客戶端用來啟用中斷的下載，或者將一個下載分成多個同步流。
207?多狀態（RFC 4918）。
后面的消息體默認是一個XML消息，可以包含多個獨立的響應代碼，這取決于有多少個子請求。
208?已報告(RFC 5842)
DAV?綁定的成員已經在（多狀態）響應的前一部分中列舉過了，現在不再包含。
226?已使用的?IM（RFC 3229）
服務器已經完成了對資源的請求，響應是對當前的一個或多個實例操作結果的表示。
【3xx重定向】
這類狀態碼表示客戶端必須采取額外的行動來完成請求。
這些狀態碼中的很多都用于URL重定向。
只有在第二請求中使用的方法是GET或HEAD的情況下，用戶代理才可以在沒有用戶交互的情況下執行附加動作。
用戶代理可以自動重定向一個請求。
用戶代理應該檢測并干預以防止周期性的重定向。
300?多項選擇
表示客戶端可以從中選擇多個資源選項（通過代理驅動的內容協商）。例如，這個代碼可以用來顯示多個視頻格式選項，列出具有不同文件擴展名的文件，或者列出多個選項。
301永久移動
當前和今后的所有請求都指向給定的URI。
302發現(原為"臨時移動")
告訴客戶端查看另一個URL。
302已經被303和307取代。
這是一個與標準相矛盾的行業實踐的例子。
HTTP/1.0規范(RFC 1945)要求客戶端執行臨時重定向，但流行的瀏覽器用303的See Other功能實現了302。
因此，HTTP/1.1增加了狀態碼303和307來區分這兩種行為。
然而，一些Web應用和框架把302的狀態碼當做303來使用。
303?見其他（自HTTP/1.1以來）
使用GET方法可以在另一個URI下找到對請求的響應。
當收到對POST（或PUT/DELETE）的響應時，客戶端應假定服務器已收到數據，并應向給定的URI發出新的GET請求。
304?未修改(RFC 7232)
表示該資源自標題請求If-Modified-Since或If-Non-Match所指定的版本后沒有被修改。
在這種情況下，不需要重新發送資源，因為客戶端仍然有一個以前下載的副本。
305?使用代理(自HTTP/1.1以來)
所請求的資源只能通過代理使用，代理的地址在響應中提供。出于安全考慮，許多HTTP客戶端（如Mozilla Firefox和Internet Explorer）不遵守這個狀態代碼。
306?交換機代理
不再使用。原意為?"以后的請求應使用指定的代理"。
307?臨時重定向（自HTTP/1.1以來）
在這種情況下，請求應該用另一個URI重發。
但是，未來的請求仍然應該使用原來的URI。
與302在歷史上的實現方式不同，在重發原始請求時不允許改變請求方法。
例如，一個POST請求應該使用另一個POST請求來重發。
308永久重定向(RFC 7538)
當前請求和以后的所有請求都應該使用另一個URI。
307和308與302和301的行為并行，但不允許HTTP方法改變。
因此，提交一個表單到一個永久重定向的資源，可能會持續下去。
【4xx?客戶端錯誤】
這類狀態代碼用于由客戶端引起的錯誤情況。
除了響應HEAD請求時，服務器應該包含一個錯誤情況的解釋實體，以及說明是暫時的還是永久的。
這些狀態代碼適用于任何請求方式。
用戶代理應該向用戶顯示所有包含的實體。
400?不良請求
由于明顯的客戶機錯誤（如：請求語法錯誤、過大、無效的請求消息或欺騙性的請求路由等），服務器無法處理請求。
401未經授權(RFC 7235)
類似于403 Forbidden，但專門用于需要認證但已經失敗或尚未提供認證的情況下使用。
響應必須包括一個WWW-Authenticate頭字段，其中包含一個適用于請求資源的挑戰。
401在語義上意味著?"未授權"，用戶沒有目標資源的有效認證憑證。
注意：當一個IP地址被禁止訪問網站時（通常是網站域名），有些網站會錯誤地發出HTTP 401。
402?需要支付
留待將來使用。
最初的意圖是，該代碼會被作為某種形式的數字現金或小額支付計劃的一部分，例如GNU Taler提出的。
但到目前還沒有發生，而且這該代碼并沒有被廣泛使用。
Google Developers API在某個特定的開發者超過了每天的請求限制時使用了這個狀態。
Sipgate在賬戶沒有足夠的資金調用時使用了這個代碼。
Shopify在商店沒有支付他們的費用而被暫時禁用時使用了這個代碼。
Stripe在屏蔽欺詐性支付時，使用了這個代碼。
403?禁止訪問
該請求包含有效的數據，而且服務器也能理解，但服務器拒絕處理。
這是由于用戶沒有必要的權限，或者需要某種類型的賬戶，或者試圖進行禁止的操作（例如，在只允許一個唯一記錄的情況下創建一個重復記錄）。
如果請求通過WWW-Authenticate頭字段提供了驗證，但服務器沒有接受該驗證，則通常也會使用此代碼。
該請求不應重復進行。
404?未找到
所請求的資源無法找到，但將來可能會有，?因此客戶端繼續請求是允許的。
405?方法不允許
不支持被請求資源的請求方法，例如，在要求通過POST顯示數據的表單上使用GET請求，或者在只讀資源上使用PUT請求。
406?不可接受
所請求的資源只能夠根據請求中發送的Accept headers生成無效的內容。
407?需要代理認證（RFC 7235）
客戶端必須先通過代理進行身份驗證。
408?請求超時
服務器超時等待請求。
根據HTTP規范的規定，客戶端沒有在服務器等待的時間內發出請求。
客戶端可在以后的任何時間不加修改地重復請求。
409?沖突
表示由于資源的當前狀態有沖突，比如多個同時更新數據之間的編輯沖突，導致請求無法處理。
410?消失
表示所請求的資源已不再可用。
當資源被故意刪除并清除資源時，應使用該代碼。
客戶端在收到410狀態碼后，今后不應再請求該資源。
客戶端（如搜索引擎）應該將該資源從其索引中刪除。
大多數用例不要求客戶端和搜索引擎清除該資源，這時可以使用?"404?未發現"代替。
411長度需指定
所請求的資源所要求的長度未指定。
412先決條件失敗(RFC 7232)
服務器不符合請求者在請求頭字段上提出的一個前提條件。
413?有效載荷過大(RFC 7231)
發出了大于服務器能夠處理的請求。以前稱為?"請求實體過大"。
414 URI Too Long (RFC 7231)
提供的URI太長，服務器無法處理。
通常是由于GET請求的查詢字符串中編碼的數據太多，?在這種情況下，應該轉換為POST請求。
以前叫?"Request-URI Too Long"。
415?不支持的媒體類型(RFC 7231)
請求實體的媒體類型在服務器上不支持。
416?范圍不滿足(RFC 7233)
客戶端請求了文件的一部分（字節服務），但服務器無法提供這一部分。例如，如果客戶端要求的文件的一部分超出了文件的末尾。
之前稱為?"Requested Range Not Satisfiable"。
417?期望落空
服務器無法滿足Expect request-header字段的要求。
418?我是茶壺（RFC 2324，RFC 7168）。
這個代碼在1998年被定義為傳統的IETF愚人節玩笑之一，在RFC 2324《超文本咖啡壺控制協議》（Hyper Text Coffee Pot Control Protocol）中，預計不會被實際的HTTP服務器實現。
RFC規定這個代碼應該由請求沖泡咖啡的茶壺返回。
這個HTTP狀態在一些網站中被用作復活節彩蛋，比如Google.com的I'm a teapot easter egg。
421錯誤定向請求（RFC 7540）
該請求是指向無法產生響應的服務器（例如連接重用）。
422?不可處理的實體（RFC 4918）
該請求的形式很好，但由于語義錯誤而無法得到實施。
423鎖定(RFC 4918)
被訪問的資源被鎖定了。
424?失敗的依賴性(RFC 4918)
該請求失敗是因為它依賴于另一個請求，而那個請求失敗了（例如，PROPPATCH）。
425過早（RFC 8470）
表示服務器不愿意冒險處理可能被重播的請求。
426?需要升級
客戶端應切換到不同的協議，如TLS/1.0等，在升級頭字段中給出。
428?所需的先決條件（RFC 6585）。
源服務器指定進行的請求是有條件的。
意在防止?"丟失更新"的問題，即客戶端GET到資源的狀態，修改它，然后把它PUT回服務器，同時第三方修改了服務器上的狀態，導致沖突。
429?太多的請求（RFC 6585）。
用戶在一定的時間內發送了太多的請求。專用于限速方案。
431?請求標題字段過大?(RFC 6585)
服務器不愿意處理請求，因為單個頭字段或所有的頭字段合起來太大。
451?由于法律原因不可用(RFC 7725)
服務器運營商收到了一個合法的要求，拒絕訪問一個資源或包括所請求的資源的資源集，選擇代碼451是為了參考小說《華氏451》（見RFC中的Acknowledgements）。
【5xx服務器錯誤】
服務器未能滿足請求。
以數字?"5 "開頭的響應狀態代碼表示服務器意識到自己遇到了錯誤或無法執行請求的情況。
除了響應HEAD請求之外，對于其他請求，服務器還應該包含一個錯誤情況解釋的實體，并說明是臨時性的還是永久性的。
同樣，用戶代理也應該向用戶顯示任何包含的實體。
這些響應代碼適用于任何請求方式。
500?內部服務器錯誤
通用的錯誤信息，當遇到意外情況而沒有更具體的信息適合時給出的通用錯誤信息。
501?未執行
服務器要么不識別該請求方法，要么缺乏實現該請求的能力。通常這意味著未來的可用性（例如，Web服務API的一個新功能）。
502不良通道
服務器作為網關或代理，收到了來自上游服務器的無效響應。
503?服務不可用
服務器無法處理該請求（如因為超載或停機維護）。一般來說，這是一種臨時狀態。
504個網關超時
該服務器作為網關或代理，沒有及時收到上游服務器的響應。
505 HTTP版本不支持
服務器不支持請求中使用的HTTP協議版本。
506變化協商(RFC 2295)
透明的內容協商請求的結果為循環引用。
507?存儲不足（RFC 4918）。
服務器無法存儲完成請求所需的表示方式。
508環路檢測（RFC 5842）。
服務器在處理請求時檢測到一個無限循環。
510未擴展（RFC 2774）
服務器需要對請求進行進一步的擴展才能滿足請求。
511?網絡認證要求(RFC 6585)
客戶端需要進行身份驗證才能獲得網絡訪問。目的是通過攔截用于控制網絡訪問的代理（例如，"圈養門戶"，要求在通過Wi-Fi熱點授予完全的互聯網訪問權之前，必須同意服務條款）。
【小結】
本文對HTTP請求所有可能涉及到的五大類狀態碼進行了學習和探討，?希望對大家有用。
HTTP
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章
