HTTP 狀态碼

狀态碼

狀态碼是來告訴用戶端，發生了什麼事情。狀态碼為用戶端提供了一種

了解事務處理結果

的

便捷方式

。狀态碼位于響應的起始行中

比如，在行 HTTP/1.0 200 OK 中，狀态碼就是200

用戶端向一個 HTTP 伺服器發送請求封包時，會遇到很多意想不到的情況，請求不一定能夠成功完成。伺服器可能會告訴你無法找到所請求的資源，你沒有通路資源的權限，或者資源被移到了其他地方

狀态碼是在每條響應封包的起始行中傳回的。會傳回一個數字狀态和一個可讀的狀态。

數字碼

便于程式進行差錯處理，而

原因短語

則便于人們了解

原因短語

原因短語是響應起始行中的最後一個元件。它為狀态碼提供了

文本形式

的解釋

比如，在行 HTTP/1.0 200 OK 中，OK 就是原因短語

原因短語和狀态碼是成對出現的。原因短語是狀态碼的

可讀

版本，應用程式開發者将其傳送給使用者，用于說明在請求間發生了什麼情況。HTTP 規範并沒有提供任何硬性規定，要求原因短語以何種形式出現

PHP面試問答： https://github.com/colinlet/PHP-Interview-QA?utm=alc

包含網絡協定、資料結構與算法、PHP、Web、MySQL、Redis、Linux、安全、設計模式、架構、自我介紹、離職原因、職業規劃、準備問題等部分

如果覺得不錯歡迎 star 關注，正在不斷持續更新中~~

狀态碼分類

五大類

可以通過三位數字代碼對不同狀态碼進行分類

• 200 到 299 之間的狀态碼表示成功
• 300 到 399 之間的代碼表示資源已經被移走了
• 400 到 499 之間的代碼表示用戶端的請求出錯了
• 500 到 599 之間的代碼表示伺服器出錯了

|狀态碼|整體範圍|已定義範圍|分類|

|-|-|-|-|

|1XX|100~199|100~101|資訊提示|

|2XX|200~299|200~206|成功|

|3XX|300~399|300~305|重定向|

|4XX|400~499|400~415|用戶端錯誤|

|5XX|500~599|500~505|伺服器錯誤|

目前的 HTTP 版本隻為每類狀态定義了幾個代碼。随着協定的發展，HTTP 規範中會正式地定義更多的狀态碼。若收到了不認識的狀态碼，可能是有人将其作為目前協定的

擴充定義

的。可以根據其所處的範圍，将它作為那個類别中一個普通的成員來處理

例如，若收到了狀态碼 515(在 5XX 代碼的已定義範圍之外)，就應該認為這條響應指出了伺服器的錯誤，這是 5XX 封包的通用類别

100 ~ 199，資訊狀态碼

HTTP/1.1 向協定中引入了資訊性狀态碼。這些狀态碼相對較新，關于其複雜性和感

知價值存在一些争論，而受到限制

|狀态碼|原因短語|含義|

|-|-|-|

|100|Continue|說明收到了請求的初始部分，請用戶端繼續。發送了這個狀态碼之後，伺服器在收到請求之後必須進行響應|

|101|Switching Protocols|說明伺服器正在根據用戶端的指定，将協定切換成 Update 首部所列的協定|

100 Continue 狀态碼的目的是對這樣的情況進行優化：HTTP 用戶端應用程式有一個實體的主體部分要發送給伺服器，但希望在發送之前檢視一下伺服器是否會接受這個實體。用戶端應用程式隻有在避免向伺服器發送一個伺服器

無法處理或使用的大實體

，才應該使用 100 Continue

200 ~ 299，成功狀态碼

用戶端發起請求時，這些請求通常都是成功的。伺服器有一組用來表示成功的狀态碼，分别對應于不同類型的請求

|200|OK|請求沒問題，實體的主體部分包含了所請求的資源|

|201|Created|用于建立伺服器對象的請求(比如:PUT)。響應的實體主體部分中應該包含引用了已建立的資源的URL，Location首部包含的則是最具體的引擎。伺服器必須在發送這個狀态碼之前建立好對象|

|202|Accepted|請求已被接受，伺服器還未對其執行任何動作。不能保證伺服器會完成這個請求；接受請求時，它看起來是有效的。伺服器應在實體的主體部分包含對請求狀态的描述，或附加請求預計處理時間、資訊擷取指針|

|203|Non-Authoritative Information|實體首部包含的資訊不是來自于源端伺服器，而是來自資源的副本。如果中間節點上有一份副本，但無法或沒有對中繼資料進行驗證，就會出現這種情況|

|204|No Content|響應封包中包含若幹首部和一個狀态行，但沒有實體的主體部分。主要用于在浏覽器不轉為顯示新文檔的情況下，對其進行更新（比如重新整理一個表單頁面）|

|205|Reset Content|另一個主要用于浏覽器的代碼。負責告知浏覽器清除目前頁面中的所有 HTML 表單元素|

|206|Partial Content|成功執行了一個部分或 Range(範圍)請求。用戶端可以通過一些特殊的首部來擷取部分或某個範圍内的文檔|

300 ~ 399，重定向狀态碼

重定向狀态碼要麼告知用戶端使用替代位置來通路他們所感興趣的資源，要麼就提供一個替代的響應而不是資源的内容。如果資源已被移動，可發送一個重定向狀态碼和一個可選的 Location 首部來告知用戶端資源已被移走，以及現在可以在哪裡找到它。這樣，浏覽器就可以在不打擾使用者的情況下，透明地轉入新的位置了

請求封包

GET /index.php HTTP/1.1
Host: blog.maplemark.cn
Accept: *           

響應封包

HTTP/1.1 301 Moved Permanently
Server: nginx/1.12.2
Date: Fri, 19 Apr 2019 03:58:59 GMT
Content-Type: text/html; charset=UTF-8
X-Powered-By: PHP/7.2.16
Location: https://blog.maplemark.cn/           

GET / HTTP/1.1
Host: blog.maplemark.cn
Accept: *           

HTTP/1.1 200 OK
Server: nginx/1.12.2
Date: Fri, 19 Apr 2019 03:59:34 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
...           

|300|Multiple Choices|用戶端請求一個實際指向多個資源的URL時會傳回這個狀态碼，比如伺服器上有某個HTML文檔有多個語言版本。傳回時會帶有一個選項清單，使用者可以選擇期望使用的那項|

|301|Moved Permanently|在請求的 URL 已被移除時使用。響應的 Location 首部中應該包含資源現在所處的 URL|

|302|Found|與 301 狀态碼類似；但是，用戶端應該使用 Location 首部給出的URL 來臨時定位資源。将來的請求仍應使用老的 URL|

|303|See Other|告知用戶端應該用另一個 URL 來擷取資源。新的 URL 位于響應封包的 Location 首部。其主要目的是允許 POST 請求的響應将用戶端定向到某個資源上去|

|304|Not Modified|用戶端可以通過所包含的請求首部，使其請求變成有條件的。若使用者發起了一個條件 GET 請求，而資源近期未被修改，可以通過該狀态碼表明。帶有這個狀态碼的響應不應該包含實體的主體部分|

|305|Use Proxy|用來說明必須通過一個代理來通路資源；代理的位置由 Location首部給出。用戶端是相對某個特定資源來解析這條響應的，不能假定所有請求，甚至所有對持有所請求資源的伺服器的請求都通過這個代理進行。如果用戶端錯誤地讓代理介入了某條請求，可能會引發破壞性的行為，而且會造成安全漏洞|

|306|(未使用)|目前未使用|

|307|Temporary Redirect|與 301 狀态碼類似；但用戶端應該使用 Location 首部給出的 URL來臨時定位資源。将來的請求應該使用老的 URL|

302、303 和 307 狀态碼之間存在一些交叉。這些狀态碼的用法有着細微的差别，大部分差别都源于 HTTP/1.0 和 HTTP/1.1 應用程式對這些狀态碼

處理方式

的不同，為相容 HTTP/1.0 而保留了一些狀态碼(例如 302 狀态碼)

400 ~ 499，用戶端錯誤狀态碼

有時用戶端會發送一些伺服器

無法處理

的東西，比如格式錯誤的請求封包，或者最常見的是，請求一個不存在的 URL

很多用戶端錯誤都是由浏覽器來處理的，甚至不會打擾到你。隻有少量錯誤，比如404，還是會穿過浏覽器來到使用者面前

|400|Bad Request|用于告知用戶端它發送了一個錯誤的請求|

|401|Unauthorized|與适當的首部一同傳回，在這些首部中請求用戶端在擷取對資源的通路權之前，對自己進行認證|

|402|Payment Required|現在這個狀态碼還未使用，但已經被保留，以作未來之用|

|403|Forbidden|用于說明請求被伺服器拒絕了。如果伺服器想說明為什麼拒絕請求，可以包含實體的主體部分來對原因進行描述。但這個狀态碼通常是在伺服器不想說明拒絕原因的時候使用的|

|404|Not Found|用于說明伺服器無法找到所請求的 URL。通常會包含一個實體，以便用戶端應用程式顯示給使用者看|

|405|Method Not Allowed|發起的請求中帶有所請求的 URL 不支援的方法時，使用此狀态碼。應該在響應中包含 Allow 首部，以告知用戶端對所請求的資源可以使用哪些方法|

|406|Not Acceptable|用戶端可以指定參數來說明它們願意接收什麼類型的實體。伺服器沒有與用戶端可接受的 URL 相比對的資源時，使用此代碼。通常，伺服器會包含一些首部，以便用戶端弄清楚為什麼請求無法滿足|

|407|Proxy Authentication Required|與 401 狀态碼類似，但用于要求對資源進行認證的代理伺服器|

|408|Request Timeout|如果用戶端完成請求所花的時間太長，伺服器可以回送此狀态碼，并關閉連接配接。逾時時長随伺服器的不同有所不同，但通常對所有的合法請求來說，都是夠長的|

|409|Conflict|用于說明請求可能在資源上引發的一些沖突。伺服器擔心請求會引發沖突時，可以發送此狀态碼。響應中應該包含描述沖突的主體|

|410|Gone|與 404 類似，隻是伺服器曾經擁有過此資源。主要用于 Web 站點的維護，這樣伺服器的管理者就可以在資源被移除的情況下通知用戶端了|

|411|Length Required|伺服器要求在請求封包中包含 Content-Length 首部時使用|

|412|Precondition Failed|用戶端發起了條件請求，且其中一個條件失敗了的時候使用。用戶端包含了 Expect 首部時發起的就是條件請求|

|413|Request Entity Too Large|用戶端發送的實體主體部分比伺服器能夠或者希望處理的要大時，使用此狀态碼|

|414|Request URI Too Long|用戶端所發請求中的請求 URL 比伺服器能夠或者希望處理的要長時，使用此狀态碼|

|415|Unsupported Media Type|伺服器無法了解或無法支援用戶端所發實體的内容類型時，使用此狀态碼|

|416|Requested Range Not Satisfiable|請求封包所請求的是指定資源的某個範圍，而此範圍無效或無法滿足時，使用此狀态碼|

|417|Expectation Failed|請求的 Expect 請求首部包含了一個期望，但伺服器無法滿足此期望時，使用此狀态碼。如果代理或其他中間應用程式有确切證據說明源端伺服器會為某請求産生一個失敗的期望，就可以發送這個響應狀态碼|

500 ~ 599，伺服器錯誤狀态碼

有時用戶端發送了一條有效請求，伺服器自身卻出錯了。這可能是用戶端碰上了伺服器的缺陷，或者伺服器上的子元素，比如某個網關資源，出了錯

代理嘗試着代表用戶端與伺服器進行交流時，經常會出現問題。代理會釋出 5XX 伺服器錯誤狀态碼來描述所遇到的問題

|500|Internal Server Error|伺服器遇到一個妨礙它為請求提供服務的錯誤時，使用此狀态碼|

|501|Not Implemented|用戶端發起的請求超出伺服器的能力範圍（比如，使用了伺服器不支援的請求方法）時，使用此狀态碼|

|502|Bad Gateway|作為代理或網關使用的伺服器從請求響應鍊的下一條鍊路上收到了一條僞響應（比如，它無法連接配接到其父網關）時，使用此狀态碼|

|503|Service Unavailable|用來說明伺服器現在無法為請求提供服務，但将來可以。如果伺服器知道什麼時候資源會變為可用的，可以在響應中包含一個 RetryAfter 首部|

|504|Gateway Timeout|與狀态碼 408 類似，隻是這裡的響應來自一個網關或代理，它們在等待另一伺服器對其請求進行響應時逾時了|

|505|HTTP Version Not Supported|伺服器收到的請求使用了它無法或不願支援的協定版本時，使用此狀态碼。有些伺服器應用程式會選擇不支援協定的早期版本|

《HTTP狀态碼》 原文連結：

https://blog.maplemark.cn/2019/04/http%E7%8A%B6%E6%80%81%E7%A0%81.html?utm=alc