HTTP 狀態碼整理

時間 2019-12-05

標籤 http 狀態整理欄目 HTTP/TCP 简体版

原文原文鏈接

文章同步於 Github blog

HTTP 狀態碼被分紅了五大類。咱們所列的是 HTTP/1.1 規範推薦使用的緣由短語。html

總體範圍	已定義範圍	分類
100 ~ 199	100 ~ 101	信息提示
200~299	200~206	成功
300 ~ 399	300 ~ 305	重定向
400 ~ 499	400 ~ 415	客戶端錯誤
500 ~ 599	500 ~ 505	服務器錯誤

100~199——信息性狀態碼

100 Continue

HTTP 100 Continue 信息型狀態響應碼錶示目前爲止一切正常, 客戶端應該繼續請求, 若是已完成請求則忽略.git

爲了讓服務器檢查請求的首部, 客戶端必須在發送請求實體前, 在初始化請求中發送 Expect: 100-continue 首部並接收 100 Continue 響應狀態碼.github

101 Switching Protocol

HTTP 101 Switching Protocol（協議切換）狀態碼錶示服務器應客戶端升級協議的請求（Upgrade請求頭）正在進行協議切換。web

服務器會發送一個Upgrade響應頭來表示其正在切換過去的協議。該過程在協議升級機制(Protocol upgrade mechanism) 中詳細描述。瀏覽器

在使用 WebSockets 時會用到協議切換。緩存

HTTP/1.1 101 Switching Protocols
Upgrade: websocket 
Connection: Upgrade

102 Processing (WebDAV)

此代碼表示服務器已收到並正在處理該請求，但沒有響應可用。服務器

200~299——成功狀態碼

客戶端發起請求時，這些請求一般都是成功的。服務器有一組用來表示成功的狀態碼，分別對應於不一樣類型的請求。websocket

200 OK

請求沒問題，實體的主體部分包含了所請求的資源。socket

201 Created

用於建立服務器對象的請求(好比，PUT)。tcp

響應的實體主體部分中應該包含各類引用了已建立的資源的 URL，Location 首部包含的則是最具體的引用。服務器必須在發送這個狀態碼以前建立好對象。

202 Accepted

請求已被接受，但服務器還未對其執行任何動做。不能保證服務器會完成這個請求；這只是意味着接受請求時，它看起來是有效的。

服務器應該在實體的主體部分包含對請求狀態的描述，或許還應該有對請求完成時間的估計(或者包含一個指針，指向能夠獲取此信息的位置)。

203 Non-Authoritative Information

實體首部（Entity headers） 包含的信息不是來自於源端服務器，而是來自資源的一份副本。

若是中間節點上有一份資源副本，但沒法或者沒有對它所發送的與資源有關的元信息(首部)進行驗證，就會出現這種狀況。

這種響應碼並非非用不可的；若是實體首部來自源端服務器，響應爲 200 狀態的應用程序就能夠將其做爲一種可選項使用。

204 No Content

服務器成功處理了請求，但不須要返回任何實體內容，而且但願返回更新了的元信息。

響應可能經過實體頭部的形式，返回新的或更新後的元信息。若是存在這些頭部信息，則應當與所請求的變量相呼應。

若是客戶端是瀏覽器的話，那麼用戶瀏覽器應保留髮送了該請求的頁面，而不產生任何文檔視圖上的變化，即便按照規範新的或更新後的元信息應當被應用到用戶瀏覽器活動視圖中的文檔。因爲204響應被禁止包含任何消息體，所以它始終以消息頭後的第一個空行結尾。

205 Reset Content

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

可是與204響應不一樣，返回此狀態碼的響應要求請求者重置文檔視圖。

該響應主要是被用於接受用戶輸入後，當即重置表單，以便用戶可以輕鬆地開始另外一次輸入。與204響應同樣，該響應也被禁止包含任何消息體，且以消息頭後的第一個空行結束。

206 Partial Content

成功執行了一個部分或 Range(範圍)請求。

相似於 FlashGet 或者迅雷這類的 HTTP 下載工具都是使用此類響應實現斷點續傳或者將一個大文檔分解爲多個下載段同時下載。

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

206 響應中必須包含 Content-Range、Date 以及 ETag 或 Content- Location 首部。

207 Multi-Status (WebDAV)

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

208 Multi-Status (WebDAV)

226 IM Used (HTTP Delta encoding)

300~399——重定向狀態碼

重定向狀態碼要麼告知客戶端使用替代位置來訪問他們所感興趣的資源，要麼就提供一個替代的響應而不是資源的內容。

若是資源已被移動，可發送一個重定向狀態碼和一個可選的 Location 首部來告知客戶端資源已被移走，以及如今能夠在哪裏找到它。這樣，瀏覽器就能夠在不打擾使用者的狀況下，透明地轉入新的位置了。

300 Multiple Choice

客戶端請求一個實際指向多個資源的 URL 時會返回這個狀態碼，比如服務器上有某個 HTML 文檔的英語和法語版本。返回這個代碼時會帶有一個選項列表;這樣用戶就能夠選擇他但願使用的那一項了。有多個版本可用時，客戶端須要溝通解決。服務器能夠在 Location 首部包含首選 URL

301 Moved Permanently

在請求的 URL 已被移除時使用。

響應的 Location 首部中應該包含資源如今所處的 URL。除非額外指定，不然這個響應也是可緩存的。

302 Found

請求的資源如今臨時從不一樣的 URI 響應請求。

因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。客戶端應該使用 Location 首部給出的 URL 來臨時定位資源。只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。

303 See Other

對應當前請求的響應能夠在另外一個 URI 上被找到，並且客戶端應當採用 GET 的方式訪問那個資源。這個方法的存在主要是爲了容許由腳本激活的POST請求輸出重定向到一個新的資源。

304 Not Modified

若是客戶端發送了一個帶條件的 GET 請求且該請求已被容許，而文檔的內容（自上次訪問以來或者根據請求的條件）並無改變，則服務器應當返回這個狀態碼。304響應禁止包含消息體，所以始終以消息頭後的第一個空行結尾。

305 Use Proxy

被請求的資源必須經過指定的代理才能被訪問。

Location 域中將給出指定的代理所在的 URI 信息，接收者須要重複發送一個單獨的請求，經過這個代理才能訪問相應資源。只有原始服務器才能創建305響應。

306 unused

在最新版的規範中，306狀態碼已經再也不被使用。

307 Temporary Redirect

請求的資源如今臨時從不一樣的URI 響應請求。

因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。

308 Permanent Redirect

請求和全部未來的請求應該使用另外一個URI重複。 307和308重複302和301的行爲，但不容許HTTP方法更改。例如，將表單提交給永久重定向的資源可能會順利進行。

400~499——客戶端錯誤狀態碼

400 Bad Request

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

401 Unauthorized

當前請求須要用戶驗證。

該響應必須包含一個適用於被請求資源的 WWW-Authenticate 信息頭用以詢問用戶信息。客戶端能夠重複提交一個包含恰當的 Authorization 頭信息的請求。

若是當前請求已經包含了 Authorization 證書，那麼401響應表明着服務器驗證已經拒絕了那些證書。

若是401響應包含了與前一個響應相同的身份驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那麼瀏覽器應當向用戶展現響應中包含的實體信息，由於這個實體信息中可能包含了相關診斷信息。

402 Payment Required

此響應碼保留以便未來使用，創造此響應碼的最初目的是用於數字支付系統，然而如今並未使用。

403 Forbidden

服務器已經理解請求，可是拒絕執行它。

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

404 Not Found

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

405 Method Not Allowed

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

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

406 Not Acceptable

客戶端能夠指定參數來講明它們願意接收什麼類型的實體。

服務器沒有與客戶端可接受的 URL 相匹配的資源時，使用此代碼。一般，服務器會包含一些首部，以便客戶端弄清楚爲何請求沒法知足。

407 Proxy Authentication Required

與401響應相似，只不過客戶端必須在代理服務器上進行身份驗證。代理服務器必須返回一個 Proxy-Authenticate 用以進行身份詢問。客戶端能夠返回一個 Proxy-Authorization 信息頭用以驗證。

408 Request Timeout

請求超時。

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

409 Conflict

因爲和被請求的資源的當前狀態之間存在衝突，請求沒法完成。

這個代碼只容許用在這樣的狀況下才能被使用：用戶被認爲可以解決衝突，而且會從新提交新的請求。該響應應當包含足夠的信息以便用戶發現衝突的源頭。

410 Gone

被請求的資源在服務器上已經再也不可用，並且沒有任何已知的轉發地址。

這樣的情況應當被認爲是永久性的。若是可能，擁有連接編輯功能的客戶端應當在得到用戶許可後刪除全部指向這個地址的引用。若是服務器不知道或者沒法肯定這個情況是不是永久的，那麼就應該使用404狀態碼。除非額外說明，不然這個響應是可緩存的。　

411 Length Required

服務器要求在請求報文中包含 Content-Length 首部時使用。

在添加了代表請求消息體長度的有效 Content-Length 頭以後，客戶端能夠再次提交該請求。

412 Precondition Failed

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

這個狀態碼容許客戶端在獲取資源時在請求的元信息（請求頭字段數據）中設置先決條件，以此避免該請求方法被應用到其但願的內容之外的資源上。

413 Payload Too Large

服務器拒絕處理當前請求，由於該請求提交的實體數據大小超過了服務器願意或者可以處理的範圍。

此種狀況下，服務器能夠關閉鏈接以避免客戶端繼續發送此請求。若是這個情況是臨時的，服務器應當返回一個 Retry-After 的響應頭，以告知客戶端能夠在多少時間之後從新嘗試。

414 URI Too Long

請求的 URI 長度超過了服務器可以解釋的長度，所以服務器拒絕對該請求提供服務。

這比較少見，一般的狀況包括：本應使用 POST 方法的表單提交變成了 GET 方法，致使查詢字符串（Query String）過長。

415 Unsupported Media Type

對於當前請求的方法和所請求的資源，請求中提交的實體並非服務器中所支持的格式，所以請求被拒絕。

416 Requested Range Not Satisfiable

若是請求中包含了 Range 請求頭，而且 Range 中指定的任何數據範圍都與當前資源的可用範圍不重合，同時請求中又沒有定義 If-Range 請求頭，那麼服務器就應當返回 416 狀態碼。

417 Expectation Failed

請求的 Expect 請求首部包含了一個指望，但服務器沒法知足此指望時，使用此狀態碼。

若是代理或其餘中間應用程序有確切證聽說明源端服務器會爲某請求產生一個失敗的指望，就能夠發送這個響應狀態碼。

418 I'm a teapot

htcpcp1.0協議中的418的意義是：當客戶端給一個茶壺發送泡咖啡的請求時，茶壺就返回一個418錯誤狀態碼，表示「我是一個茶壺」。

421 Misdirected Request

The request was directed at a server that is not able to produce a response. This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI.

422 Unprocessable Entity (WebDAV)

The request was well-formed but was unable to be followed due to semantic errors.

423 Locked (WebDAV)

The resource that is being accessed is locked.

424 Failed Dependency (WebDAV)

The request failed due to failure of a previous request.

426 Upgrade Required

The server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server sends an Upgrade header in a 426 response to indicate the required protocol(s).

428 Precondition Required

The origin server requires the request to be conditional. Intended to prevent the 'lost update' problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.

429 Too Many Requests

The user has sent too many requests in a given amount of time ("rate limiting").
431 Request Header Fields Too Large
The server is unwilling to process the request because its header fields are too large. The request MAY be resubmitted after reducing the size of the request header fields.

451 Unavailable For Legal Reasons

The user requests an illegal resource, such as a web page censored by a government.

服務端響應

500 Internal Server Error

服務器遇到了不知道如何處理的狀況。

501 Not Implemented

客戶端發起的請求超出服務器的能力範圍(好比，使用了服務器不支持的請求方法)時，使用此狀態碼

502 Bad Gateway

做爲代理或網關使用的服務器從請求響應鏈的下一條鏈路上收到了一條僞響應(好比，它沒法鏈接到其父網關)時，使用此狀態碼。

503 Service Unavailable

用來講明服務器如今沒法爲請求提供服務，但未來能夠。

若是服務器知道何時資源會變爲可用的，能夠在響應中包含一個 Retry- After 首部。

504 Gateway Timeout

與狀態碼 408 相似，只是這裏的響應來自一個網關或代理，它們在等待另外一服務器對其請求進行響應時超時了

505 HTTP Version Not Supported

服務器收到的請求使用了它沒法或不肯支持的協議版本時，使用此狀態碼。有些服務器應用程序會選擇不支持協議的早期版本

506 Variant Also Negotiates

The server has an internal configuration error: transparent content negotiation for the request results in a circular reference.

507 Insufficient Storage

The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.