RFC2616-HTTP1.1-Status Code(狀態碼規定部分—譯文)

part of Hypertext Transfer Protocol -- HTTP/1.1

RFC 2616 Fielding, et al.

10 狀態碼規定（Status Code Definitions）

　　本文描述了每個狀態碼的相關規定，包括了對應狀態碼須要遵循的方法和在響應中須要的任何元信息。

10.1 Informational 1xx

　　該類狀態碼錶示臨時性的響應，僅由狀態行和可選的頭部組成，並由一個空行結束。該類狀態碼沒有必須的頭部字段。因爲HTTP／1.0沒有定義任何1xx狀態碼，除非在實驗條件下，服務器不能向HTTP／1.0客戶端發送1xx響應。

　　在一個有規律的響應返回以前，客戶端必須準備好接受可能的一個或多個1xx響應，即便客戶端並不須要100(Continue)狀態消息。不須要的1xx響應狀態可能會被客戶端所忽略。

　　代理必須轉發1xx響應，即便代理和它的客戶端的連接已經關閉了，或者，除非代理自己要求生成1xx響應。（舉個栗子，代理在轉發請求時添加了「Expect：100-continue」字段，那麼它不須要轉發相應的100（Continue）字段）。

10.1.1 100 Continue

　　客戶端應繼續發送其請求。該臨時響應用於通知客戶端請求的初始部分已經被接受而且還沒有被服務器拒絕。在請求結束後，服務器必須返回一個最終的響應。查看 8.2.3 小節得到有關該狀態碼更詳細的內容。

10.1.2 101 切換協議（Switching Protocols）

　　服務器理解並願意遵循客戶端的請求，經過升級消息頭字段（14.42小節），來修改在該連接上使用的應用協議。服務器在空行終止101響應以後會當即對那些包含UpGrade頭字段的響應切換協議。

　　只有在有利的狀況下，才應該切換協議。舉個栗子，切換到較新版本的HTTP比舊版本更有利，而且在傳遞使用這些特徵的資源時切換到實時、同步協議多是更有利的。

10.2 Successful 2xx

　　該類狀態碼錶示客戶端的請求已經被成功接收，理解和接受。

10.2.1 200 OK

　　請求已經成功。在響應中返回的信息取決於在請求中使用的方法，例如：

　　GET  與請求的資源相一致的實體會在響應中返回；

　　HEAD 與請求的資源相一致的實體頭字段會在響應中返回，響應返回的內容沒有任何的消息體（message-body）；

　　POST 一個描述或包含執行結果的實體；

　　TRACE 包含終端服務器接收到的請求消息的實體。

10.2.2 201 Created（已建立）

　　請求已經完成，並致使一個新的資源被建立。新建立的資源能夠被響應實體中返回的URI所引用，該資源所引用的指定URI在Location頭字段中給出。響應應該包括一個實體，該實體包含一個資源特性和位置的列表，用戶或用戶代理能夠從中選擇最合適的一個。實體的格式是由Content-Type頭字段中的媒體類型所指定的。元服務器必須在返回201狀態碼以前生成相應的資源。若是執行結果沒法被當即解析，那麼服務器須要用202(Accepted)響應來替代。

　　一個201響應可能會包含一個ETag響應頭字段，該字段表示剛剛建立的請求變量的實體標籤的當前值，詳情請見14.19小節。

10.2.3 202 Accepted（已接收）

　　請求已經被接受並在處理，可是處理尚未完成。請求最終可能會、也可能不會被處理，由於在處理實際發生的問題時它多是被禁止的。在像這樣的異步操做中沒法從新發送一個狀態碼。

　　202響應是有意不表態的。它的目的是容許服務器接收其它進程的請求(也許一個批處理(batch-oriented)進程一天只執行一次)，無需用戶代理與服務器的鏈接一直持續到進程完成。使用此響應返回的實體應該包括請求的當前狀態的說明和指向狀態監視器的指針或用戶什麼時候才能預期該請求已經完成的估計。

10.2.4 203 Non-Authoritative Information（非受權信息）

　　實體頭中返回的元信息不是元服務器可用的最終集合，可是是從本地或者第三方拷貝的。所呈現的集合能夠是原始版本的子集或父集。例如，包含有關資源的本地註釋信息有可能成爲元服務器已知的源信息的父集。只有在響應爲200的狀況下才適用此響應碼。

10.2.5 204 No Content（無內容）

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

　　若是客戶端是一個用戶代理，則不該該從它在請求發送的文檔中改變它的文檔視圖。此響應主要用於容許輸入的動做而不引發對用戶代理的活動文檔視圖的更改，儘管任何新的或更新的元信息都應應用於當前在用戶代理的活動視圖中的文檔。

　　204響應無需包括消息主體，所以老是由頭字段以後的第一個空行終止。

10.2.6 205 Reset Content（重置內容）

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

10.2.7 206 Partial Content（部份內容）

　　服務器已經完成了部分GET請求的資源的獲取。該請求必須包含一個Range頭字段(14.35小節)指按期望獲取內容的範圍，而且可能包含一個If-Range頭字段（14.27小節）以使請求視條件而定。

　　該請求的響應必須包含下列頭字段：

　　　 -  該響應須要包含一個描述範圍的Content-Range頭字段，要麼就每個部分都須要一個包含Content-Range字段的多部分/字節範圍(multipart/byteranges)的
Content-Type字段。若是該響應中存在Content-Length頭字段，它的值必須與信息體中傳輸的八位字節數值相匹配。

      - Date

　　　 - ETag和（或）Content-Location，若是消息頭將以200的形式響應給相同的請求。

　　　 - Expires,Cache-Control,和（或）Vary，若是字段值不一樣於以前爲相同變體所發送的任何響應的值。

　　若是206響應是一個使用強緩存驗證的If-Range請求的結果(詳情請看13.3.3), 該響應則不該該包含其它實體頭。若是該相應是一個使用弱緩存驗證的If-Rang請求的結果，那麼響應中則必定不能包含其它實體頭。這是爲了防止緩存後的實體與更新後的頭字段不一致的問題。不然，對於那些已經返回200響應的同一個請求，那麼該響應必須包含全部的實體頭。

　　若是ETag或Last-Modified頭字段不匹配，那麼緩存則必定不能將206響應與其它以前已經緩存的內容組合在一塊兒。（詳情請看13.5.4小節）

　　一個未提供Range和Content-Range的頭字段必定不能緩存206響應。

10.3 重定向（Redirection） 3xx

　　這類狀態代碼指示爲了完成請求，須要由用戶代理採起進一步的動做。當且僅當第二次請求是GET或HEAD請求時，所需的動做能夠僅由用戶代理來執行而不與用戶交互。客戶端應該檢測無限重定向循環，由於這樣的循環會使每一個重定向都生成網絡流量。

      Note:本規範的之前版本建議最多重定向五次。開發人員應該意識到可能有客戶端存在這樣一個固定的限制。

10.3.1 300 多種選擇（Multiple Choices）

　　所請求的資源與代理資源集合中的任何一個都匹配，每個都有其指定的地址，而且提供了代理驅動（agent-driven）的相關協商信息（第12小節）可讓用戶或者用戶代理能夠選擇一個更優的代理並重定向該請求到此地址。

　　即便是一個HEAD請求，響應也須要包含一個實體，該實體還有一個相關資源類目的列表和地址，這樣可讓用戶或者用戶代理選擇一個最匹配的資源做爲結果。實體格式由Content-Type頭字段指定的媒體類型決定。根據用戶代理的格式和能力，能夠自動執行最合適的選擇。然而，該規範沒有定義任何有關於這種自動選擇的標準。

　　若是服務器有一個優先的選擇，他應該在Location字段中包含該指定資源的URI。用戶代理可能會用Location字段值來自動重定向。除非另有說明，不然此響應是能夠緩存的。

10.3.2 301 永久移除（Moved Permanently）

　　請求的資源已經分配了一個新的永久URI，而且任何對該資源的將來引用都應該使用返回的URI之一。具備連接功能的客戶端應該在可能的狀況下，自動將引用到的「請求URI(Request-URI)」的引用從新連接到服務器返回的一個或多個新的引用上。

　　新的永久URI須要在響應中的Location字段註明。

　　若是響應一個請求而接收到的是301狀態的請求方法不是HEAD或者GET，那麼用戶代理就不能自動重定向該請求，除非用戶能夠確認該請求，由於這樣可能會改變請求所發出的條件。

　　Note：當收到301狀態碼後自動重定向POST請求時，一些現有的HTTP/1.0用戶代理將錯誤地將其更改成GET請求。
　

10.3.3 302 已發現(Found)

　　請求的資源暫時存儲在不一樣的URI下。因爲重定向有時可能會被更改，因此客戶端應該繼續使用該「請求URI(Request-URI)」用於將來的請求。該響應僅在被Cache-Control或Expires頭字段描述的時候會被緩存。

　　臨時的URI應該由響應中的Location字段提供。除非請求方法是HEAD，不然響應的實體應該包含一個短超文本註釋，其中帶有指向新URI的超連接。

　　若是響應一個請求而接收到的是302狀態的請求方法不是HEAD或者GET，那麼用戶代理就不能自動重定向該請求，除非用戶能夠確認該請求，由於這樣可能會改變請求所發出的條件。　　

　　Note:RFC 1945和RFC 2068指定不容許客戶端對重定向請求更改方法。然而，大多數現有的用戶代理實現都將302視爲303響應，在位置字段值上執行GET，而無論原始請求方法是什麼。對於那些但願明確代表客戶指望的反應類型
的服務器，已經添加了狀態代碼303和307。

10.3.4 303 參見其餘(See Other)

　　對請求的響應能夠在不一樣的URI下找到，應該使用該資源上的GET方法來檢索。該方法主要用於容許POST激活（POST-activated）的腳本的輸出將用戶代理重定向到所選擇的資源。新的URI不是最初請求的資源的替代引用。303響應不能被緩存，可是該響應的第二次（或重定向）請求可能會被緩存。

　　不一樣的URI須要在響應的Location字段中給出。除非請求方法是HEAD，不然響應的實體應該包含一個短超文本註釋，其中帶有指向新URI的超連接。

      Note:不少HTTP/1.1以前版本的協議不理解303狀態。當須要與此類客戶端進行交互性操做時，可使用302狀態碼，由於大多數的用戶代理對302狀態的響應就像這裏所描述的303同樣。

10.3.5 304 未修改(Not Modified)

　　若是客戶端執行了有條件的GET請求並容許訪問，可是文件沒有修改，此狀態碼應該用該狀態碼來響應。304響應不能包含一個消息體，所以，老是以頭字段後的第一個空行結束。

該響應必須包含如下的頭部字段：

      - Date, 除非他是按照14.18.1章節所描述的被要求遺漏的

　　若是無時鐘的服務器遵循這些規則，而且代理和客戶端將本身的日期添加到沒有收到服務器日期的任何響應中(如[RFC 2068]第14.19節中已經指定的)，緩存將正確運行。

      - ETag 和（或） Content-Location, 若是消息頭將以200響應的形式發送給相同的請求。

      - Expires, Cache-Control, 和(或) Vary, 若是字段值可能與以前的響應中所發送的相同的變量是不同的。

　　若是有條件的GET請求使用了一個強緩存驗證（詳情請看13.3.3小節），響應不能包括其餘實體頭字段。不然（即有條件的GET請求使用弱驗證），響應必定不能包含其餘實體頭。這能夠防止緩存的實體和已更新的頭字段之間的不一致。

　　若是304響應表示當前未緩存的實體，則緩存必須忽略響應並從新發起一個無條件的請求。

　　若是一個緩存使用了接收到的304響應來更新一個緩存條目，那麼該緩存必須更新該條目以反映在響應中給定的任何新的字段值。

10.3.6 305 使用代理（Use Proxy）

　　所請求的資源必須經過Location字段所提供的代理進行訪問。Location字段提供了代理的URI地址。接收方但願經過代理重複此單個請求。305響應必須僅由源服務器生成。

      Note: RFC 2068協議並不清楚305是否打算重定向單個請求，而且僅由原始服務器生成。不遵照這些限制會產生重大的安全後果。

10.3.7 306 (已廢棄)

　　306狀態碼在本規範的前一個版本中使用，目前再也不使用，而且代碼被保留。

10.3.8 307  臨時重定向（Temporary Redirect）

　　請求的資源臨時存儲在另外一個URI下。因爲該重定向有時可能會被修改，因此將來的客戶端請求仍舊使用原請求URI。該響應僅在使用了Cache-Control或者Expires頭字段描述的時候纔會被緩存。

　　臨時URI的地址須要在響應中的Location中給出。除非請求方法是HEAD，不然響應的實體應該包含一個簡短的超文本註釋，並帶有到新URI的超連接，由於許多http /1.1以前版本的用戶代理不理解307狀態。所以，註釋應該包含用戶在新URI上從新開始原始請求所需的信息。

　　若是在響應中收到了307狀態碼，可是該響應的請求方法不是HEAD或者GET，用戶代理必定不能自動重定向該請求，除非它已經被用戶所確認，由於這可能會改變發出請求時的條件。

10.4  客戶端錯誤（Client Error） 4xx

　　4xx類的狀態碼是爲了描述客戶端的錯誤。除了響應HEAD請求之外，服務器應該包含一個有着錯誤狀況解釋的實體，以及它是臨時的仍是永久的。該類狀態碼適用於任何請求方法。客戶代理須要爲用戶顯示任何在響應中包含的實體內容。

　　若是客戶端正在發送數據，那麼使用TCP的服務器實現應該在服務器關閉輸入鏈接以前確保客戶端確認收到包含響應的數據包。若是客戶端在關閉後繼續向服務器發送數據，那麼服務器的TCP堆棧將向客戶機發送一個重置包，這可能會在HTTP應用程序讀取和解釋以前清除客戶端未確認的輸入緩衝區。

10.4.1 400 非法請求（Bad Request）

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

10.4.2 401 未經受權的（Unauthorized）

　　在發出請求時須要驗證用戶的身份信息。響應必須包含一個適用於所請求資源的用於詢問的WWW-Authenticate頭字段（14.47小節）。客戶端可使用合適的Authorization頭字段重複該請求（14.8小節）。若是請求已經包含了受權驗證相關信息，而後401響應代表這些證書已經被拒絕受權。若是3-1響應包含了與以前響應相同的詢問信息，而且用戶代理至少已經嘗試過一次認證，而後向用戶顯示響應中給出的實體，由於該實體可能包括相關的診斷信息。HTTP詢問相關的身份驗證的詳細說明在「HTTP身份驗證:簡單扼要地訪問身份驗證[43]」中。

10.4.3 402 支付要求（Payment Required）

　　該狀態碼會在將來提供使用方法。

10.4.4 403 被拒絕的（Forbidden）

　　服務器理解相應的請求，可是拒絕該請求。受權不會有幫助，請求也不該該被重複。若是請求方法不是HEAD而且服務器但願公開請求爲何沒有完成，它應該在實體中說明拒絕的緣由。若是服務器不但願將此信息提供給客戶端，那麼可使用404狀態碼來代替。

10.4.5 404 未找到（Not Found）

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

10.4.6 405 方法不被容許（Method Not Allowed）

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

10.4.7 406 沒法接受（Not Acceptable）

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

　　除非是一個HEAD請求，響應應該包含一個有着可用實體特徵和位置列表的實體，用戶或用戶代理能夠從中選擇最合適的實體內容。實體格式由Content-Type頭字段中給出的媒體類型指定。根據用戶代理的格式和能力，能夠自動執行最合適的選擇。然而，該規範沒有定義任何用於這種自動選擇的標準。

      Note: 服務器容許根據請求中發送的請求頭返回不可接受的響應。在某些狀況下，這甚至可能比發送406響應更好。咱們鼓勵用戶代理檢查傳入響應的報頭，以肯定是否能夠接受。

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

10.4.8 407 須要代理驗證身份（Proxy Authentication Required）

　　該狀態碼和401(Unauthorized)有些相似，但指示客戶端必須首先用代理進行身份驗證。代理必須返回一個Proxy-Authenticate頭字段（14.33小節），該字段包含適用於所請求資源的代理的相關詢問。客戶端須要在重複該請求時包含一個合適的Proxy-Authorization頭字段。http相關的訪問驗證說明在「HTTP Authentication: Basic and Digest Access Authentication」 [43]中有詳細的介紹。

10.4.9 408 請求超時（Request Timeout）

　　客戶端沒有在服務器準備等待的時間內生成請求。客戶端能夠在之後的任什麼時候候重複該請求而不作任何修改。

10.4.10 409 衝突（Conflict）

　　因爲與資源的當前狀態發生衝突，請求沒法完成。只有在預期用戶可以解決衝突並從新提交請求的狀況下才容許使用此代碼。相迎體須要包含足夠的信息讓用戶意識到該資源的衝突。理想狀況下，響應實體將包含足夠的信息給用戶或用戶代理來解決問題；然而，這多是不可能的，而且不是必需的。

　　衝突最有可能發生在響應PUT請求時。例如，若是當前的資源正在使用版本控制，即將被PUT的資源包含了一些修改，這些修改還會引發以前（或第三方）請求的衝突，服務器須要使用409響應來講明它沒法完成該請求。在這種狀況下，響應實體可能包含兩個版本之間的差別列表，格式由響應中的Content-Type定義。

10.4.11 410 已刪除（Gone）

　　請求的資源已經不被服務器所提供，而且沒有已知的地址可指向該資源。這種狀況有望被認爲是永久的。具備連接編輯功能的客戶端應該在用戶批准後刪除對該請求uri的引用。若是服務器不知道，或者沒有肯定的條件知道它的狀態是不是永久的，那麼則應該使用404狀態碼。除非另有說明，該響應是能夠緩存的。

　　410響應主要是經過通知接收方資源是不可用的，而且服務器全部者但願移除該資源的遠程連接來協助Web維護的任務。這樣的狀況對於有時間限制的資源、促銷服務和屬於再也不在服務器站點工做的我的的資源來講是常見的。不須要將全部永久不可用的資源標記爲「已用（GONE）」，也不須要將標記保留任什麼時候間——這由服務器全部者自行決定。

10.4.12 411 須要長度（Length Required）

　　服務器拒絕接受沒有Content-Length頭字段的請求。若是客戶端在請求消息中添加包含消息正文長度的有效的Content-Length頭字段，則能夠重複該請求。

10.4.13 412 未知足前提條件（Precondition Failed）

　　在服務器上測試請求頭字段時，在一個或多個請求頭字段中給出的先決條件被評估爲false。此響應碼容許客戶端在當前資源的元信息(header字段數據)上放置先決條件，從而防止請求的方法被應用到預期資源以外的資源。

10.4.14 413 請求實體過大（Request Entity Too Large）

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

　　若是條件是臨時的，服務器應該包含Retry-After頭字段，以代表它是臨時的，而且在什麼時候能夠再次嘗試該請求。

10.4.15 414 請求URI過長（Request-URI Too Long）

　　因爲請求URI過長，超過了服務器所能解析的極限，因此服務器拒絕爲該請求提供服務。這種罕見的狀況只可能發生在客戶端將一個POST請求不當的轉換成爲一個具備過長的查詢(query)信息的GET請求的時候，當客戶端進入URI重定向的「黑洞」（好比，一個重定向URI的前綴指向了它自身的後綴），或者當服務器遭到客戶端攻擊時，試圖利用固定長度緩衝器來讀取某些服務器中存在的安全漏洞，以讀取或操縱請求URI。

10.4.16 415 不支持的媒體類型（Unsupported Media Type）

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

10.4.17 416 沒法知足的請求範圍（Requested Range Not Satisfiable）

　　若是一個請求中包含看Range請求頭字段，而且此字段中的範圍說明符值均不與所選資源的當前範圍重疊，而且請求中並無If-Range請求頭字段，那麼服務器應該在響應中返回該狀態碼。（對於byte-ranges字段，它說明在全部字節範圍中的第一字節值都大於所選資源的當前長度。）

　　當該狀態碼爲響應一個byte-range請求而返回，該響應須要包含一個Content-Range實體頭字段，用來講明當前所選擇資源的長度（詳情請看 14.16小節）。該響應不能使用multipart/byteranges類型。

10.4.18 417 未知足Expect頭字段所標識的信息（Expectation Failed）

　　該服務器沒法知足Expect 頭部字段（見第14.20節）中的指望，或者，若是服務器是代理服務器，則服務器有明確的證據代表該請求不能被下一跳（next-hop）服務器所知足。

10.5 服務器錯誤（Server Error） 5xx

　　以數字「5」開頭的響應狀態碼錶示服務器意識到它已經出錯或沒法執行請求的狀況。除了響應頭部請求以外，服務器還應該返回一個包含解釋錯誤狀況的實體，以及它是不是臨時的或永久性的狀態。代理應該向用戶展現全部的實體內容。這些響應碼適合任何請求方法。

10.5.1 500 內部服務器錯誤（Internal Server Error）

　　服務器遇到了一個意外狀況，阻止了它完成相應的請求。

10.5.2 501 未實現（Not Implemented）

　　服務器不支持完成請求所需的功能。當服務器沒法識別請求的方法或者沒法提供任何資源的時候，應該返回該響應。

10.5.3 502 壞網關（Bad Gateway）

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

10.5.4 503 服務不可用（Service Unavailable）

　　因爲服務器的臨時過載或維護，服務器目前沒法處理該請求。這意味着，這是一個暫時的狀態，將在一些延遲後獲得緩解。若是已知延遲的時間，那麼延遲的長度可能會在Retey-After頭字段中表示。若是沒有提供Retry-After字段，客戶端應該像處理500響應那樣處理該響應。

Note: 503狀態代碼的存在並不意味着服務器在重載時必須使用它。有些服務器可能簡單地但願拒絕鏈接。

10.5.5 504 網關超時（Gateway Timeout）

　　服務器做爲網關或代理，沒有收到來自URI（例如HTTP、FTP、LDAP）或在試圖完成請求時須要訪問的其餘輔助服務器（例如DNS）所指定的上游服務器的及時響應。

      Note: 開發者注意:當DNS查找超時時，已知一些已部署的代理返回400或500。

10.5.6 505 不支持的HTTP版本（HTTP Version Not Supported）

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