史上最全的狀態碼

10狀態代碼定義

每一個狀態碼描述以下，其中描述的方法（S）能夠遵循和響應所需的任何信息。

 

10.1信息1xx

此類狀態碼錶示臨時響應，僅由狀態行和可選標頭組成，並由空行終止。這類狀態碼沒有必需的頭文件。因爲HTTP / 1沒有定義任何1xx狀態碼，服務器不能發送一個HTTP 1客戶端1xx響應除了在實驗條件。

 

客戶端必須準備接受一個或多個1xx狀態響應的一種常規響應以前，即便客戶不期望100（繼續）狀態信息。意外的1xx狀態響應能夠由一個用戶代理忽略。

 

代理人必須向前1xx響應，除非代理和客戶端之間的鏈接已關閉，或除非代理自己要求的一代1xx響應。（例如，若是

 

代理在轉發請求時添加一個「指望值：100」字段，而後它不須要轉發相應的100（繼續）響應。

 

10.1.1 100繼續

客戶機應繼續其請求。此臨時響應用於通知客戶機已收到請求的初始部分，還沒有被服務器拒絕。客戶端應該繼續發送請求的剩餘部分，或者，若是請求已經完成，則忽略此響應。服務器必須在請求完成後發送最終響應。看到的使用做了詳細的討論與此狀態代碼處理8.2.3節。

 

10.1.2 101交換協議

服務器理解並願意聽從客戶端的請求，經過升級消息頭字段（第14.42節），以更改在該鏈接上使用的應用程序協議。服務器將在終止101響應的空行以後當即將協議轉換爲響應的升級頭字段定義的協議。

 

只有在有利於這樣作的狀況下，才應該交換協議。例如，切換到較新版本的HTTP對舊版本有利，在交付使用這些特性的資源時，切換到實時同步協議多是有利的。

 

10.2成功的2xx

這類狀態代碼代表客戶的請求被成功地接收、理解和接受。

 

10.2.1 200 OK

請求成功了。響應返回的信息依賴於請求中使用的方法，例如：

 

獲取響應請求中發送的與請求資源相對應的實體；

 

頭與請求的資源相對應的實體頭字段在響應中發送，沒有任何消息體；

 

張貼描述或包含行動結果的實體；

 

跟蹤包含端服務器接收的請求消息的實體。

 

10.2.2 201建立

請求已經完成，並建立了一個新資源。新建立的資源能夠由響應實體中返回的URI引用，其中位置標頭字段提供的資源具備最具體的URI。響應應該包括一個實體，其中包含一個資源特性列表和位置，用戶或用戶代理能夠從中選擇最合適的一個。實體格式是由內容類型頭字段中指定的媒體類型指定的。在返回201狀態碼以前，源服務器必須建立資源。若是不能當即執行該操做，則服務器應以202（接受）響應代替。

 

201響應可能包含ETag響應頭域表示的變體標籤實體的要求爲剛剛建立的電流值，見14.19節。

 

10.2.3 202接受

請求已接受處理，但處理還沒有完成。請求可能會或可能不會最終將採起行動，由於它多是不容許在處理實際發生。沒有從異步操做中從新發送狀態碼的工具，如。

 

202迴應是故意不表態。它的目的是容許服務器接受對其餘進程的請求（多是隻面向一天運行一次的批處理過程），而不要求用戶代理與服務器的鏈接一直存在，直到過程完成。返回此響應的實體應該包括請求當前狀態的指示，或者指向狀態監視器的指針，或者用戶什麼時候能夠知足請求的一些估計。

10.2.4 203非權威信息

在實體報頭返回的元信息是不明確的設置爲從源服務器，而是從本地或第三方複製彙集。設置可能被提出的子集或超集的原始版本。例如，包括對資源的地方標註信息可能會致使由原始服務器稱爲元信息的一個超集。使用此響應代碼是不須要的，只有在響應爲200時才合適（OK）。

 

10.2.5 204無內容

服務器已經完成了請求，但不須要返回一個實體，而且但願返回更新的元信息。響應可能包括新的或更新的形式在實體頭信息，若是存在，應與請求的變量相關聯。

 

若是客戶端是一個用戶代理，它不該該改變它的文檔視圖，從而致使發送請求。這種反應主要是爲了讓行動不會致使改變用戶代理的活動文檔視圖發生輸入，但任何新的或更新的信息應該被應用到文檔中的用戶代理的積極見解。

 

204個響應不能包含消息體，所以老是在頭字段以後的第一個空行終止。

 

版本205內容復位

服務器已經完成了請求，用戶代理應該重置文檔視圖，從而致使請求被髮送。此響應主要是爲了容許經過用戶輸入進行操做的輸入，隨後輸入輸入的表單，以便用戶能夠容易地啓動另外一個輸入操做。響應不能包含實體。

 

10.2.7 206部份內容

服務器完成了資源的部分GET請求。請求必須包含一個範圍標頭字段（第14.35節），指示指望的範圍，而且可能包括一個if範圍標頭字段（第14.27節），使請求有條件。

 

響應必須包括如下頭字段：

 

-表示內容範圍標頭字段（第14.16節）

範圍包括與此響應，或多重/ byteranges

內容類型，包括每一個部分的內容範圍字段。若是一個

內容長度頭字段存在於響應中，其

值必須匹配發送的字節的實際數量

消息體。

-日期

- ETag和/或內容位置，若是頭文件已發送

在對同一請求的200響應中

-若是字段值可能，過時、緩存控制和/或更改

與之前對同一響應的發送不一樣

變體

若是206響應是一個結果，若是範圍要求用強緩存驗證（見第13.3.3），響應不該包括其餘實體頭。若是反應是一個結果，若是範圍要求用弱驗證器，響應必須不包括其餘實體頭；這樣能夠防止緩存之間的實體機構和更新的標題不一致。不然，響應必須包含全部的實體標頭，這些標頭都將返回對同一請求的200（OK）響應。

 

緩存不能結合206響應緩存的內容若是與其餘先前的ETag或最後修改標題不徹底匹配，看到13.5.4。

 

不支持範圍和內容範圍標頭的緩存不能緩存206（部分）響應。

 

10.3重定向3xx

這類狀態碼代表，爲了知足請求，用戶代理須要採起進一步的操做。所需的動做能夠由用戶代理進行，而沒必要與用戶交互，且僅當第二個請求中使用的方法是get或頭時。客戶機應該檢測無限重定向循環，由於這樣的循環爲每一個重定向生成網絡流量。

 

注意：本規範的前一版本建議

五重定向的最大。內容開發人員應該知道

可能有客戶實現了這樣一個固定的

限制。

10.3.1 300多種選擇

所請求的資源對應於一組表示的任何一個，每個都有其本身的特定位置，而且正在提供代理驅動的協商信息（第12節），以便用戶（或用戶代理）能夠選擇一個優選表示並將其請求重定向到該位置。

 

除非是頭請求，響應應該包含一個實體，其中包含一個資源特性列表和位置，用戶或用戶代理能夠選擇最合適的位置。實體格式是由內容類型頭字段中給定的媒體類型指定的。取決於格式和功能

 

能夠自動執行用戶代理，選擇最合適的選擇。可是，該規範沒有定義此類自動選擇的任何標準。

 

若是服務器具備首選的表示方式，則應該包含該位置字段中該表示的特定URI；用戶代理可使用位置字段值進行自動重定向。這個響應是可緩存的除非另有說明。

 

10.3.2 301永久移動

被請求的資源已經被分配了一個新的URI和任何將來的資源引用到這應該用一個返回的URI。具備連接編輯功能的客戶端應該自動將請求URI的引用從新連接到服務器返回的一個或多個引用，若是可能的話。這個響應是可緩存的除非另有說明。

 

新的永久URI應該由響應中的位置字段給出。除非請求方法爲頭，不然響應的實體應該包含一個超文本超文本註釋，並帶有新URI的超連接。

 

若是響應了GET或頭部之外的請求而接收到301狀態碼，則用戶代理不能自動重定向請求，除非用戶能夠確認它，由於這可能會更改發出請求的條件。

 

注意：當自動重定向POST請求後

接收到301狀態碼，一些現有的HTTP / 1用戶代理

將錯誤地將其更改成GET請求。

10.3.3 302發現

請求的資源暫時駐留在不一樣的URI下。因爲重定向有時可能被更改，客戶機應該繼續使用請求URI來知足未來的請求。這種反應只緩存若是表示緩存控制或Expires頭域。

 

臨時URI應該由響應中的位置字段給出。除非請求方法爲頭，不然響應的實體應該包含一個超文本超文本註釋，並帶有新URI的超連接。

 

若是響應了GET或頭部之外的請求而接收到302狀態碼，則用戶代理不能自動重定向請求，除非用戶能夠確認它，由於這可能會更改發出請求的條件。

 

注意：RFC 1945和RFC 2068指定不容許客戶端。

更改重定向請求的方法。然而，最

現有的用戶代理實現將302視爲303。

響應，在位置字段值上執行get，無論

對原始請求的方法。狀態碼303和307

爲但願明確說明的服務器添加

客戶須要某種反應。

10.3.4 303看其餘

對請求的響應能夠在不一樣的URI下找到，應該使用該資源上的get方法檢索。此方法主要存在於容許激活後腳本將用戶代理重定向到選定資源。新URI不是原始請求資源的替代引用。303響應必須不被緩存，但反應到二（重定向）的要求多是緩存。

 

響應中的位置字段應該給出不一樣的URI。除非請求方法爲頭，不然響應的實體應該包含一個超文本超文本註釋，並帶有新URI的超連接。

 

注意：許多HTTP / 1.1用戶代理不理解303。

現狀。當與此類客戶機的互操做性受到關注時，

可使用302狀態碼，由於大多數用戶代理都會做出反應。

到302的響應，這裏描述的是303。

10.3.5 304不改

若是客戶機執行了條件GET請求並容許訪問，但文檔沒有被修改，服務器應該使用此狀態代碼進行響應。304個響應不能包含消息體，所以老是在頭字段以後的第一個空行終止。

 

響應必須包括如下頭字段：

 

日期，除非其不做爲是以部分14.18.1要求

若是無時鐘源服務器遵循這些規則，和代理和客戶本身添加日期的任何反應沒有收到一個（由[ ]已經指定RFC 2068，14.19節），緩存將正確操做。

 

- ETag和/或內容位置，若是頭文件已發送

在對同一請求的200響應中

-若是字段值可能，過時、緩存控制和/或更改

與之前對同一響應的發送不一樣

變體

若是使用了強緩存驗證獲得的條件（見第13.3.3），響應不該包括其餘實體頭。不然（即，有條件的習慣弱驗證器），響應必須不包括其餘實體頭；這樣能夠防止緩存之間的實體機構和更新的標題不一致。

 

若是304響應表示當前未緩存的實體，則緩存必須忽略響應並在沒有條件的狀況下重複請求。

 

若是緩存使用接收到的304響應來更新緩存條目，則緩存必須更新條目，以反映響應中給出的任何新字段值。

 

10.3.6 305使用代理

請求的資源必須經過位置字段提供的代理訪問。位置字段給出代理的URI。收件人但願經過代理重複這一請求。305響應必須僅由原始服務器生成。

 

注意：RFC 2068不清楚，305是爲了重定向一個

單個請求，只由原始服務器生成。不

觀察這些限制會產生重大的安全後果。

10.3.7 306（未使用）

306狀態代碼在之前版本的規範中使用，再也不使用，代碼被保留。

 

10.3.8 307臨時重定向

請求的資源暫時駐留在不一樣的URI下。因爲重定向有時可能被更改，客戶機應該繼續使用請求URI來知足未來的請求。這種反應只緩存若是表示緩存控制或Expires頭域。

 

臨時URI應該由響應中的位置字段給出。除非請求方法爲頭，不然響應的實體應該包含一個超連接的超文本註釋，該連接具備新的URI的超連接，由於許多前HTTP / 1.1用戶代理不理解307狀態。所以，註釋應該包含用戶在新URI上重複原始請求所必需的信息。

 

若是響應了GET或頭部之外的請求而接收到307狀態碼，則用戶代理不能自動重定向請求，除非用戶能夠確認它，由於這可能會更改發出請求的條件。

 

10.4 4客戶端錯誤

狀態代碼4xx類爲例，客戶彷佛有錯。除了對頭請求做出響應外，服務器應該包含一個包含錯誤狀況解釋的實體，以及它是不是臨時的或永久的條件。這些狀態碼適用於任何請求方法。用戶代理應該向用戶顯示任何包含的實體。

 

若是客戶機正在發送數據，使用TCP的服務器實現應該當心，以確保在服務器關閉輸入鏈接以前，客戶機確認接收包含響應的數據包。若是客戶端繼續發送數據到服務器後，服務器的TCP協議棧將發送一個重置數據包到客戶端，從而才能閱讀和HTTP應用解釋刪除客戶端的未確認的輸入緩衝器。

 

10.4.1 400錯誤的請求

因爲語法錯誤，服務器沒法理解請求。客戶機不該在不修改的狀況下重複請求。

10.4.2 401未經受權

該請求須要用戶身份驗證。響應必須包含一個WWW驗證頭字段（第14.47節），其中包含適用於所請求資源的挑戰。客戶端能夠用適當的受權頭字段重複請求（第14.8節）。若是請求已包含受權憑據，則401響應表示已拒絕這些憑據的受權。若是401響應包含與前面的響應相同的挑戰，而且用戶代理至少已經嘗試過一次身份驗證，那麼應該向用戶展現響應中給出的實體，由於該實體可能包含相關的診斷信息。HTTP訪問驗證在「HTTP認證：基本和摘要訪問驗證」中解釋（43）。

 

10.4.3 402付款要求

此代碼保留以備未來使用。

 

10.4.4沒有權限訪問此網站

服務器理解了請求，但拒絕履行它。受權無效，請求不該重複。若是請求方法不是頭，服務器但願公開爲何請求沒有完成，它應該描述實體拒絕的緣由。若是服務器不但願將此信息提供給客戶機，則可使用狀態碼404（未找到）。

 

10.4.5 404未找到

服務器沒有找到與請求URI匹配的任何內容。沒有跡象代表這種狀況是暫時性的仍是永久性的。若是服務器經過某種內部可配置的機制知道舊資源是永久不可用且沒有轉發地址的，則應該使用410（離開）狀態代碼。當服務器不但願確切地揭示拒絕請求的緣由，或者沒有其餘響應時，一般使用這種狀態代碼。

 

10.4.6 405法不容許

請求行中指定的方法不容許由請求URI標識的資源。響應必須包含一個容許標頭，其中包含所請求資源的有效方法列表。

 

406不接受單獨

由請求標識的資源僅可以生成響應實體，這些內容具備不能根據請求中發送的接收頭接受的內容特徵。

 

除非是頭請求，響應應包括一個實體，其中包含可用實體特性和位置的列表，用戶或用戶代理能夠從中選擇最合適的一個實體。實體格式是由內容類型頭字段中指定的媒體類型指定的。根據用戶代理的格式和功能，能夠選擇自動執行最合適的選擇。可是，該規範沒有定義此類自動選擇的任何標準。

 

注意：容許HTTP / 1.1服務器返回響應

根據接收到的接收頭不能接受

請求。在某些狀況下，這甚至比發送一個

406響應。鼓勵用戶代理檢查

輸入響應以肯定是否可接受。

若是響應是不可接受的，用戶代理應該暫時中止接收更多數據，並查詢用戶對進一步行動的決定。

 

10.4.8 407代理服務器要求身份驗證

此代碼相似於401（未經受權），但表示客戶端必須首先用代理進行身份驗證。代理必須返回一個代理驗證頭字段（第14.33節），其中包含適用於請求資源代理的挑戰。客戶機可使用適當的代理受權頭字段重複請求（第14.34節）。HTTP訪問驗證在「HTTP認證：基本和摘要訪問驗證」中解釋（43）。

 

10.4.9 408請求超時

客戶機在服務器準備等待的時間內沒有生成請求。客戶能夠在不修改的狀況下重複請求。

 

10.4.10 409衝突

因爲與資源的當前狀態發生衝突，請求沒法完成。此代碼只容許的狀況下，預計用戶可能可以解決衝突和從新提交請求。響應主體應包括足夠

 

用戶識別衝突源的信息。理想狀況下，響應實體將包含足夠的信息以供用戶或用戶代理解決問題；然而，這多是不可能的，也不是必需的。

 

衝突最有可能發生在對提交請求的響應中。例如，若是正在使用版本控制，而且實體被包含到與早期（第三方）請求所產生的資源發生衝突的地方，那麼服務器可能會使用409響應來指示它不能完成請求。在這種狀況下，響應實體可能包含一個由響應內容類型定義的格式的兩個版本之間的差別列表。

 

10.4.11 410了

請求的資源在服務器上再也不可用，而且沒有已知的轉發地址。這種狀況預計將被視爲永久性的。具備連接編輯功能的客戶端應該在用戶批准後刪除對請求URI的引用。若是服務器不知道，或者沒有肯定的條件，條件是不是永久的，則應該使用狀態碼404（未找到）。這個響應是可緩存的除非另有說明。

 

410個響應主要是爲了幫助Web維護的任務，通知接收方資源是不可用的，服務器全部者但願刪除該資源的遠程連接。這樣的事件在有限的時間、促銷服務和屬於再也不在服務器站點工做的我的的資源中是常見的。沒有必要將全部永久不可用資源標記爲「消失」或保留任什麼時候間的標記——這是由服務器全部者自行決定的。

 

10.4.12 411長度要求

服務器拒絕接受沒有定義內容長度的請求。若是在請求消息中添加一個包含消息主體長度的有效內容長度頭字段，客戶機能夠重複請求。

 

10.4.13 412前提條件失敗

在服務器上進行測試時，一個或多個請求頭字段中給出的前提條件被評估爲false。此響應代碼容許客戶在條件對當前資源元信息（標題字段數據），從而防止所請求的方法被應用到比預期的另一個資源。

 

10.4.14 413請求實體太大

服務器拒絕處理請求，由於請求實體比服務器願意或可以處理的要大。服務器能夠關閉鏈接以防止客戶端繼續請求。

 

若是條件是臨時的，服務器應該包含一個重試頭字段來指示它是臨時的，在客戶端重試以後。

 

10.4.15 414請求URI太長

服務器拒絕服務請求，由於請求URI比服務器願意解釋的時間長。這種罕見的狀況只可能發生在客戶端不當將POST請求轉換到一個GET長查詢信息，當客戶進入一個URI的「黑洞」的重定向（例如，重定向的URI前綴指向自己的後綴），或者當服務器經過客戶端試圖利用安全漏洞使用固定長度的緩衝區讀或操縱請求一些服務器目前的攻擊下。

 

10.4.16 415不支持的媒體類型

服務器拒絕提供請求，由於請求的實體是所請求的資源不支持所請求方法的格式。

 

10.4.17 416請求範圍不知足

若是一個請求的服務器應該包含一系列請求標頭字段返回此狀態碼的響應（14.35節），沒有一個範圍說明符值在這一領域的重疊選定當前資源的程度，並要求不包括若是範圍請求標頭字段。（對於字節範圍，這意味着全部字節範圍規範值的第一個字節的POS數大於所選資源的當前長度。）

 

當返回一個字節範圍請求的狀態代碼時，響應應該包括一個內容範圍實體頭字段，指定選定資源的當前長度（參見第14.16節）。這種反應不是必須使用多重/ byteranges內容類型。

 

10.4.18 417期待失敗

在指望的請求頭字段（見第14.20部分）中給出的指望不能被該服務器知足，或者，若是服務器是一個代理，服務器就有明確的證據證實下一跳服務器不能知足請求。

 

10.5 5服務器錯誤

響應狀態碼「5」表示在何種狀況下服務器知道它犯了錯誤或執行請求的能力。除了對頭請求做出響應外，服務器應該包含一個包含錯誤狀況解釋的實體，以及它是不是臨時的或永久的條件。用戶代理應該向用戶顯示任何包含的實體。這些響應代碼適用於任何請求方法。

 

10.5.1 500內部服務器錯誤

服務器遇到意外狀況，阻止了它執行請求。

 

10.5.2 501未實現

服務器不支持實現請求所需的功能。當服務器不識別請求方法而且不能支持任何資源時，這是適當的響應。

 

10.5.3 502網關錯誤

服務器做爲網關或代理，在試圖知足請求時從它訪問的上游服務器接收到無效的響應。

 

10.5.4 503服務不可用

因爲暫時超載或維護服務器，服務器目前沒法處理請求。這意味着這是一個暫時的條件，在一些延遲以後會獲得緩解。若是已知，則延遲長度能夠在報頭後重試。若是未重試，則客戶端應處理響應，如500響應。

 

注：503狀態碼的存在並不意味着

服務器在超載時必須使用它。有些服務器可能但願

拒絕鏈接。

10.5.5 504網關超時

服務器做爲網關或代理，並無從URI（如HTTP、FTP、LDAP）或其餘輔助服務器（如DNS）所指定的上游服務器那裏得到及時響應，在試圖完成請求時須要訪問該服務器。

 

注意：注意實施者：一些部署代理是衆所周知的

返回400或500時，DNS查詢超時。

10.5.6 505 HTTP版本不受支持

服務器不支持或拒絕支持請求消息中使用的HTTP協議版本。服務器指示它不能或不肯意使用與客戶端相同的主要版本完成請求，如第3.1節所述，與此錯誤消息不一樣。響應應該包含一個實體，描述爲何不支持該版本以及該服務器支持的其餘協議。