關於HTTP狀態碼 整體分類 1**狀態,部分請求 2**狀態,成功 3**狀態,重定向 4**狀態客戶端錯誤 5**狀態服務端錯誤 參考

本文將對http協議中的狀態碼進行總結。

整體分類

HTTP狀態碼由三個十進制數字組成,第一個十進制數字定義了狀態碼的類型,後兩個數字沒有分類的作用。HTTP狀態碼共分爲5種類型:
分類分類描述
1**信息,服務器收到請求,需要請求者繼續執行操作
2**成功,操作被成功接收並處理
3**重定向,需要進一步的操作以完成請求
4**客戶端錯誤,請求包含語法錯誤或無法完成請求
5**服務器錯誤,服務器在處理請求的過程中發生了錯誤

一個相對完整的概括:

當服務器響應時,其狀態行的信息爲HTTP的版本號,狀態碼,及解釋狀態碼的簡單說明。現將5類狀態碼詳細列出:
① 客戶方錯誤
100  繼續
101  交換協議
② 成功
200  OK
201  已創建
202  接收
203  非認證信息
204  無內容
205  重置內容
206  部分內容
③ 重定向
300  多路選擇
301  永久轉移
302  暫時轉移
303  參見其它
304  未修改(Not Modified)
305  使用代理
④ 客戶方錯誤
400  錯誤請求(Bad Request)
401  未認證
402  需要付費
403  禁止(Forbidden)
404  未找到(Not Found)
405  方法不允許
406  不接受
407  需要代理認證
408  請求超時
409  衝突
410  失敗
411  需要長度
412  條件失敗
413  請求實體太大
414  請求URI太長
415  不支持媒體類型
⑤ 服務器錯誤
500  服務器內部錯誤
501  未實現(Not Implemented)
502  網關失敗
504  網關超時
505 HTTP版本不支持

1**狀態,部分請求

100, 客戶端應當繼續,並沒有拒絕,客戶端應當發送剩餘部分
101, 理解了客戶端請求,通過Upgrade通知客戶端採用不同協議(只有有好處時才這樣切換協議)
102, WebDav擴展,處理將被繼續執行

2**狀態,成功

200, 請求成功並將返回
201, 請求實現,並且建立資源
202, 請求接受,提前返回,並將異步處理不保證完全成功
203, 請求成功,並返回非原始信息,與200相對
204, 請求成功,只返回實體頭部沒有內容,並且客戶端不更新視圖(但是可能會使用返回信息中的最新變量等)
205, 請求成功,只返回實體頭部沒有內容,並且客戶端更新視圖(比如重置表單便於後續輸入)
206, 部分GET請求,比如斷點續傳(Content-Range, Content-Length, multipart/byteranges多段下載的Content-Type,Date/ETag/Expire,Catch-Control,If-Range, Last-Modified等等)
207, WebDav擴展,之後將有XML消息並有獨立的響應代碼。

關於204的應用,來源:https://www.runoob.com/http/http-header-fields.html

響應頭中的Refresh,表示瀏覽器應該在多少時間之後刷新文檔,還可以通過setHeader("Refresh", "5; URL=http://host/path")讓瀏覽器讀取指定的頁面。 也可通過設置HTML頁面HEAD區的<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path">實現,Refresh的意義是"N秒之後刷新本頁面或訪問指定頁面",而不是"每隔N秒刷新本頁面或訪問指定頁面"。因此,連續刷新要求每次都發送一個Refresh頭,而發送204狀態代碼則可以阻止瀏覽器繼續刷新,不管是使用Refresh頭還是<META HTTP-EQUIV="Refresh" ...>。 
注意Refresh頭不屬於HTTP 1.1正式規範的一部分,而是一個擴展,但Netscape和IE都支持它。

3**狀態,重定向

300, 會有一個可選列表讓用戶或瀏覽器自行選擇其一進行重定向,非HEAD要有列表實體(Content-Type規定格式),響應Location指定首選URI,默認緩存響應。
301, 永久轉移,後將用備選新URI(可能用新URI替換請求)。新永久URI響應Location指定,默認緩存。非HEAD給出實體URI鏈接和描述。非GET/HEAD不重定向。
注:某些HTTP/1.0瀏覽器POST得到301響應後,後續的重定向將變爲GET方式。
302, 臨時重定向,仍用原有地址,新URI響應Location指定,藉助Cache-Control/Expire緩存響應,非HEAD給出實體URI鏈接和描述。非GET/HEAD不重定向。
注:很多現存瀏覽器將302視作303,並用GET訪問Location的URI,而無視原先請求的方法。藉助303/307用以明確服務端期待客戶端進行何種反應。
303, 新URI在相應Location給出不替代原始URI,客戶端應用GET方式從新URI訪問,禁止緩存但是第二個請求可以被緩存。非HEAD給出實體URI鏈接和描述。
注:許多HTTP/1.1以前的瀏覽器不理解303,但是從瀏覽器互動角度302可以勝任,因爲多數客戶端實現302的響應就是要求客戶端處理303的響應。
304,帶有條件的GET請求,文檔內容沒變,沒有消息體。響應頭必須有:Date,ETag和/或Content-Location,Expires,Cache-Control和/或Vary
請求使用弱緩存驗證(條件GET),響應無實體頭避免與內容不一致,請求使用強緩存驗證,則不應該包含實體頭。
響應指明某實體未緩存則緩存系統忽視響應,並重新發送無限制條件請求;304響應要求更新某緩存條目則緩存系統更新。
305, 通過代理訪問,Location指定代理URI,接收者重複發送單獨請求,通過代理訪問。只有原始服務器才能建立305響應。
注:305並未明確是爲重定向單獨請求,而是隻被原始服務器建立。
306,廢棄。
307, 臨時重定向地址在響應Location中,繼續以原址請求,只能藉助Cache-Control/Expire才能緩存,非HEAD給出實體URI鏈接和描述。非GET/HEAD不重定向。

關於304的解釋,來源:https://www.runoob.com/http/http-header-fields.html

響應頭中的Last-Modified會用到,該頭標識
文檔的最後改動時間。客戶可以通過If-Modified-Since請求頭提供一個日期,該請求將被視爲一個條件GET,只有改動時間遲於指定時間的文檔纔會返回,否則返回一個304(Not Modified)狀態。Last-Modified也可用setDateHeader方法來設置。

關於302的解釋,來源:https://www.runoob.com/http/http-header-fields.html

響應頭中的Location,表示客戶應當到哪裏去提取文檔。Location通常不是直接設置的,而是通過HttpServletResponse的sendRedirect方法,該方法同時設置狀態代碼爲302。

4**狀態客戶端錯誤

400, 請求語義有誤不應重複提交、參數有誤。
401, 要求用戶驗證。響應包含WWW-Authenticate信息,請求包含相應的Authorization證書。401表示拒絕相應證書。
402, 預留。
403, 理解請求但拒絕執行。不能重複提交也與驗證無關的拒絕。非HEAD服務器可在實體描述拒絕的原因;或404不讓客戶端獲取任何信息。
404, 請求失敗,被請求資源未找到。並不提示狀況是否永久,若服務器知道情況應用410表明舊資源永久無用並無跳轉,404廣泛用於不想告知原因及無合適響應情形。
405, 不能使用請求行中方法請求資源。響應通過Allow來指明接收的方法列表。大多數網頁服務器不支持PUT, DELETE等對服務器寫操作的請求,響應此405錯誤。
406, 資源內容無法滿足請求頭條件,無法生成響應實體。非HEAD請求響應返回列表實體,讓用戶或瀏覽器選擇合適的特性及地址,實體格式Content-Type定義。
407, 類似401響應, 需要在代理服務器上身份驗證。代理服務器返回Proxy-Authenticate詢問,請求返回Proxy-Authorization信息頭以驗證。
408, 請求超時。服務器等待時間內客戶端未完成請求發送,可以隨時重新請求。
409, 被請求資源衝突請求無法完成。用戶能解決衝突且可重新提交時響應該代碼,響應含幫助發現衝突源的信息。如通常PUT請求會有409錯誤,與之前的別人請求衝突可能給出差異。
410, 資源已永久性不可用,且不含轉發地址。響應可緩存,如服務器無法確定是否永久,可以使用404。主要用於維護網站,如限時、增值服務及個人資源不可用等。
411, 在沒有Content-Length頭定義時,服務器拒絕請求。添加請求消息長度的Content-Length後,客戶端可重新發請求。
412, 服務器驗證沒能滿足條件。這允許客戶端在請求頭設置先決條件,避免請求方法用在希望之外的資源上。
413, 拒絕處理請求。請求的實體數據大小超過限制,服務器可關閉鏈接以免客戶端繼續發送。臨時狀況可發送一個Retry-After頭指定可重新嘗試的時間。
414, 因請求URI長度超出限制而拒絕。如POST變成GET而參數過長,重定向導致URI累加過長,安全漏洞攻擊URI緩存溢出導致任意代碼執行(無此漏洞的服務器返回414)
415, 請求方法提供的資源其實體並非服務器所支持的格式。
416, 請求頭Range範圍與實際不重合且無If-Range請求頭。若Range是字節範圍則表示超過資源長,服務器響應同時包含Content-Range實體頭並被禁止multipart。
417, 請求頭Expect內容無法被服務器滿足,或者服務是代理可證明下一個路由節點Expect無法被滿足。
421, 客戶端IP到服務器連接數超過服務器允許範圍。比如服務器看到的客戶端地址是網關或代理服務器等,可能涉及不知一個終端用戶。
422, 請求格式正確,但是語義錯誤,無法響應(RFC4918 WebDAV)
423,資源被鎖定(RFC4918 WebDAV)
424, 由於之前某個請求錯誤導致當前請求錯誤(如PROPPATCH)(RFC4918 WebDAV)
425,在WebDav Advanced Collections 草案中定義,但是未出現在《WebDAV 順序集協議》(RFC 3658)中。
426,客戶端應當切換到TLS/1.0。(RFC 2817)
449,由微軟擴展,代表請求應當在執行完適當的操作後進行重試。

關於401的應用,來源:https://www.runoob.com/http/http-header-fields.html

響應頭中的WWW-Authenticate,客戶應該在Authorization頭中提供什麼類型的授權信息?在包含401(Unauthorized)狀態行的應答中這個頭是必需的。
注意Servlet一般不進行這方面的處理,而是讓Web服務器的專門機制來控制受密碼保護頁面的訪問(例如.htaccess)。

5**狀態服務端錯誤

500,服務器未知狀況導致它無法處理(比如服務器代碼問題)。
501,服務器不支持請求所需功能。無法識別請求方法,且無法支持其任何資源請求。
502,做爲網關或代理收到上游無效響應。
503,臨時服務器維護或過載,過段時間會恢復。響應中會有Retry-After表明預計的延遲,如果沒有當作500處理。(其實不一定過載可能是服務器不希望拒絕客戶端)
504,做爲網關或代理,並未及時從上游(URI標識的,如HTTP,FTP,LDAP)或輔助服務器(如DNS)收到響應。某些服務器會在DNS查詢超時返回(400或500)
505,服務不支持或拒絕支持請求中使用的Http版本。響應應包含爲何不支持該版本以及服務器支持哪些協議的實體。
506,《透明內容協商協議》(RFC 2295)擴展,服務器內部配置錯誤:被請求協商變元資源被配置爲在透明內容協商中用自己,因此在一協商處理中不是一合適的重點。
507,服務器無法存儲完成請求所必須的內容。這個狀況被認爲是臨時的。WebDAV (RFC 4918)
509,服務器達到帶寬限制。這不是一個官方的狀態碼,但是仍被廣泛使用。
510,獲取資源所需要的策略並沒有沒滿足。(RFC 2774)

參考

  • HTTP狀態碼: 菜鳥教程中的解釋,通俗易懂,包括常用的、整體的(大類)、細節的(細節類別)狀態碼含義情況。細節的並不是很完整。
  • httpstatus.cn: 一個表格,便於查閱,信息解釋比較詳細,每個狀態碼都有額外鏈接。
  • HTTP狀態碼(響應碼): 便於查詢的表格,有列出支持的http版本,表格版本相對舊一些。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章