【前端 · 面試 】HTTP 總結（四）—— HTTP 狀態碼

這是我參與8月更文挑戰的第4天，活動詳情查看：8月更文挑戰

最近我在作前端面試題總結系列，感興趣的朋友能夠添加關注，歡迎指正、交流。

爭取每一個知識點可以多總結一些，至少要作到在面試時，針對每一個知識點均可以侃起來，不至於啞火。

前言

經過前面的總結，咱們都知道，當客戶端經過 HTTP 向服務端發送了一個請求以後，老是指望服務端可以進行響應。而在服務端的響應結果中，信息頭會包含一個叫 Status Code 的屬性，其值爲一個三位數的數字，咱們將這個數字稱爲 HTTP 狀態碼。

HTTP 狀態碼 是 HTTP 協議的重要組成部分，它用來表示服務端對當前請求的響應狀態。

概念

HTTP 狀態碼（英語：HTTP Status Code）是用來表示網頁服務器 HTTP 協議響應狀態的 3 位數字代碼。

它由 RFC 2616 規範定義的，並獲得 RFC 251八、RFC 281七、RFC 229五、RFC 2774 與 RFC 4918 等規範擴展。

全部狀態碼的第一個數字表明瞭響應的五種狀態之一。所示的消息短語是典型的，可是能夠提供任何可讀取的替代方案。

分類

HTTP 狀態碼分爲五類，以下圖所示：

1xx 消息

這一類型的狀態碼，表明請求已被接受，須要繼續處理。有如下特性：

• 這類響應是臨時響應，只包含狀態行和某些可選的響應頭信息，並以空行結束。
• 因爲HTTP/1.0協議中沒有定義任何1xx狀態碼，因此除非在某些試驗條件下，服務器禁止向此類客戶端發送1xx響應。
• 這些狀態碼錶明的響應都是信息性的，標示客戶應該等待服務器採起進一步行動。

100 Continue

服務器已經接收到請求頭，而且客戶端應繼續發送請求主體（在須要發送身體的請求的狀況下：例如，POST請求），或者若是請求已經完成，忽略這個響應。

服務器必須在請求完成後向客戶端發送一個最終響應。

要使服務器檢查請求的頭部，客戶端必須在其初始請求中發送 Expect: 100-continue 做爲頭部，並在發送正文以前接收100 Continue狀態代碼。

101 Switching Protocols

服務器已經理解了客戶端的請求，並將經過Upgrade消息頭通知客戶端採用不一樣的協議來完成這個請求。在發送完這個響應最後的空行後，服務器將會切換到在Upgrade消息頭中定義的那些協議。

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

102 Processing

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

103 Early Hints

用來在最終的HTTP消息以前返回一些響應頭。

2xx 成功

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

200 OK

請求已成功，請求所但願的響應頭或數據體將隨此響應返回。出現此狀態碼是表示正常狀態。

201 Created

請求已經被實現，並且有一個新的資源已經依據請求的須要而創建，且其 URI 已經隨Location 頭信息返回。

假如須要的資源沒法及時創建的話，應當返回 '202 Accepted'。

202 Accepted

服務器已接受請求，但還沒有處理。正如它可能被拒絕同樣，最終該請求可能會也可能不會被執行。在異步操做的場合下，沒有比發送這個狀態碼更方便的作法了。

返回202狀態碼的響應的目的是容許服務器接受其餘過程的請求（例如某個天天只執行一次的基於批處理的操做），而沒必要讓客戶端一直保持與服務器的鏈接直到批處理操做所有完成。

接受請求處理並返回202狀態碼的響應，應當在返回的實體中包含一些指示處理當前狀態的信息，以及指向處理狀態監視器或狀態預測的指針，以便用戶可以估計操做是否已經完成。

203 Non-Authoritative Information

服務器已成功處理了請求，但返回的實體頭部元信息不是在原始服務器上有效的肯定集合，而是來自本地或者第三方的拷貝。當前的信息多是原始版本的子集或者超集。例如，包含資源的元數據可能致使原始服務器知道元信息的超集。使用此狀態碼不是必須的，並且只有在響應不使用此狀態碼便會返回200 OK的狀況下才是合適的。

204 No Content

服務器成功處理了請求，但不須要返回任何實體內容，而且但願返回更新了的元信息。響應可能經過實體頭部的形式，返回新的或更新後的元信息。若是存在這些頭部信息，則應當與所請求的變量相呼應。

若是客戶端是瀏覽器的話，那麼用戶瀏覽器應保留髮送了該請求的頁面，而不產生任何文檔視圖上的變化，即便按照規範新的或更新後的元信息應當被應用到用戶瀏覽器活動視圖中的文檔。

因爲204響應被禁止包含任何消息體，所以它始終以消息頭後的第一個空行結尾。

205 Reset Content

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

可是與204響應不一樣，返回此狀態碼的響應要求請求者重置文檔視圖。該響應主要是被用於接受用戶輸入後，當即重置表單，以便用戶可以輕鬆地開始另外一次輸入。

與204響應同樣，該響應也被禁止包含任何消息體，且以消息頭後的第一個空行結束。

206 Partial Content

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

該請求必須包含 Range 頭信息來指示客戶端但願獲得的內容範圍，而且可能包含 If-Range 來做爲請求條件。

響應必須包含以下的頭部域：

• Content-Range 用以指示本次響應中返回的內容的範圍；若是是 Content-Type 爲 multipart/byteranges 的多段下載，則每一 multipart 段中都應包含 Content-Range 域用以指示本段的內容範圍。假如響應中包含 Content-Length，那麼它的數值必須匹配它返回的內容範圍的真實字節數。

• Date

• ETag 和/或 Content-Location，假如一樣的請求本應該返回200響應。

• Expires, Cache-Control，和/或 Vary，假如其值可能與以前相同變量的其餘響應對應的值不一樣的話。

假如本響應請求使用了 If-Range 強緩存驗證，那麼本次響應不該該包含其餘實體頭；假如本響應的請求使用了 If-Range 弱緩存驗證，那麼本次響應禁止包含其餘實體頭；這避免了緩存的實體內容和更新了的實體頭信息之間的不一致。不然，本響應就應當包含全部本應該返回200響應中應當返回的全部實體頭部域。

假如 ETag 或 Last-Modified 頭部不能精確匹配的話，則客戶端緩存應禁止將206響應返回的內容與以前任何緩存過的內容組合在一塊兒。

207 Multi-Status

由WebDAV(RFC 2518)擴展的狀態碼，表明以後的消息體將是一個XML消息，而且可能依照以前子請求數量的不一樣，包含一系列獨立的響應代碼。

208 Already Reported

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

226 IM Used

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

3xx 重定向

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

當且僅當後續的請求所使用的方法是 GET 或者 HEAD 時，用戶瀏覽器才能夠在沒有用戶介入的狀況下自動提交所須要的後續請求。

客戶端應當自動監測無限循環重定向（例如：A->A，或者A->B->C->A），由於這會致使服務器和客戶端大量沒必要要的資源消耗。

按照 HTTP/1.0 版規範的建議，瀏覽器不該自動訪問超過5次的重定向。

300 Multiple Choices

被請求的資源有一系列可供選擇的回饋信息，每一個都有本身特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器可以自行選擇一個首選的地址進行重定向。

除非這是一個 HEAD 請求，不然該響應應當包括一個資源特性及地址的列表的實體，以便用戶或瀏覽器從中選擇最合適的重定向地址。這個實體的格式由 Content-Type 定義的格式所決定。瀏覽器可能根據響應的格式以及瀏覽器自身能力，自動做出最合適的選擇。固然，RFC 2616規範並無規定這樣的自動選擇該如何進行。

若是服務器自己已經有了首選的回饋選擇，那麼在 Location 中應當指明這個回饋的 URI；瀏覽器可能會將這個 Location 值做爲自動重定向的地址。此外，除非額外指定，不然這個響應也是可緩存的。

304 Not Modified

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

306 Switch Proxy

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

4xx 客戶端錯誤

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

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

400 Bad Request

有兩種可能：

• 語義有誤，當前請求沒法被服務器理解。除非進行修改，不然客戶端不該該重複提交這個請求。
• 請求參數有誤。

401 Unauthorized

當前請求須要用戶驗證。該響應必須包含一個適用於被請求資源的 WWW-Authenticate 信息頭用以詢問用戶信息。客戶端能夠重複提交一個包含恰當的 Authorization 頭信息的請求。若是當前請求已經包含了 Authorization 證書，那麼401響應表明着服務器驗證已經拒絕了那些證書。若是401響應包含了與前一個響應相同的身份驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那麼瀏覽器應當向用戶展現響應中包含的實體信息，由於這個實體信息中可能包含了相關診斷信息。

403 Forbidden

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

404 Not Found

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

405 Method Not Allowed

請求行中指定的請求方法不能被用於請求相應的資源。該響應必須返回一個Allow 頭信息用以表示出當前資源可以接受的請求方法的列表。

鑑於 PUT，DELETE 方法會對服務器上的資源進行寫操做，於是絕大部分的網頁服務器都不支持或者在默認配置下不容許上述請求方法，對於此類請求均會返回405錯誤。

406 Not Acceptable

請求的資源的內容特性沒法知足請求頭中的條件，於是沒法生成響應實體。

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

408 Request Timeout

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

5xx 服務端錯誤

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

這些狀態碼適用於任何響應方法。

500 Internal Server Error

服務器遇到了一個不曾預料的情況，致使了它沒法完成對請求的處理。通常來講，這個問題都會在服務器端的源代碼出現錯誤時出現。

501 Not Implemented

服務器不支持當前請求所須要的某個功能。當服務器沒法識別請求的方法，而且沒法支持其對任何資源的請求。

502 Bad Gateway

做爲網關或者代理工做的服務器嘗試執行請求時，從上游服務器接收到無效的響應。

503 Service Unavailable

因爲臨時的服務器維護或者過載，服務器當前沒法處理請求。這個情況是臨時的，而且將在一段時間之後恢復。若是可以預計延遲時間，那麼響應中能夠包含一個 Retry-After 頭用以標明這個延遲時間。若是沒有給出這個 Retry-After 信息，那麼客戶端應當以處理500響應的方式處理它。

注意：503狀態碼的存在並不意味着服務器在過載的時候必須使用它。某些服務器只不過是但願拒絕客戶端的鏈接。

504 Gateway Timeout

做爲網關或者代理工做的服務器嘗試執行請求時，未能及時從上游服務器（URI標識出的服務器，例如HTTP、FTP、LDAP）或者輔助服務器（例如DNS）收到響應。

注意：某些代理服務器在DNS查詢超時時會返回400或者500錯誤

505 HTTP Version Not Supported

服務器不支持，或者拒絕支持在請求中使用的 HTTP 版本。這暗示着服務器不能或不肯使用與客戶端相同的版本。響應中應當包含一個描述了爲什麼版本不被支持以及服務器支持哪些協議的實體。

507 Insufficient Storage

服務器沒法存儲完成請求所必須的內容。這個情況被認爲是臨時的。

511 Network Authentication Required

客戶端須要進行身份驗證才能得到網絡訪問權限，旨在限制用戶羣訪問特定網絡。

總結

經過 HTTP 狀態碼，咱們能夠判斷當前服務端的狀態。

狀態碼基本分爲五類，每一類中又分爲多個不一樣小類，對應的內容較多，咱們只須要知道其中一些常見的狀態碼含義便可。

~

~ 本文完，感謝閱讀！

~

~

學習有趣的知識，結識有趣的朋友，塑造有趣的靈魂！

你們好，我是〖編程三昧〗的做者 隱逸王，個人公衆號是『編程三昧』，歡迎關注，但願你們多多指教！

你來，懷揣指望，我有墨香相迎！ 你歸，不管得失，惟以餘韻相贈！

知識與技能並重，內力和外功兼修，理論和實踐兩手都要抓、兩手都要硬！