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]第
節中已經指定的)，緩存将正确運作。
- 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”
中有詳細的介紹。
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節中所描述的，而不是使用此錯誤消息。響應應該包含一個實體，說明為什麼不支援該版本以及該伺服器支援哪些其他協定。
一隻想要飛得更高的小菜鳥
![HTTP 錯誤 403.9 - 禁止通路：連接配接的使用者過多 XP IIS伺服器連接配接數的修改[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)