HTTP協議中狀態碼的含義
當瀏覽者訪問一個網頁時，瀏覽者的瀏覽器會向網頁所在服務器發出請求。當瀏覽器接收並顯示網頁前，此網頁所在的服務器會返回一個包含HTTP狀態碼的信息頭（server header）用以響應瀏覽器的請求。
HTTP狀態碼的英文為HTTP Status Code。 下面是常見的HTTP狀態碼：
- 200 - 請求成功
- 301 - 資源（網頁等）被永久轉移到其它URL
- 404 - 請求的資源（網頁等）不存在
- 500 - 內部服務器錯誤
HTTP狀態碼的分類
HTTP狀態碼由三個十進制數字組成，第一個十進制數字定義了狀態碼的類型，后兩個數字沒有分類的作用。HTTP狀態碼共分為5種類型：
| 分類 | 分類描述 |
|---|---|
| 1** | 信息，服務器收到請求，需要請求者繼續執行操作 |
| 2** | 成功，操作被成功接收並處理 |
| 3** | 重定向，需要進一步的操作以完成請求 |
| 4** | 客戶端錯誤，請求包含語法錯誤或無法完成請求 |
| 5** | 服務器錯誤，服務器在處理請求的過程中發生了錯誤 |
10.狀態碼定義
每一個狀態碼在下面定義，包括此狀態碼依賴於方法的描述和響應里需要的任何元信息的描述。10.1 通知的 1xx
這類狀態代碼指明了一個臨時性的響應，包含一個Status-Line和可選的頭域，並且被一個空行結束（空行就是CRLF）。這類狀態碼響應沒有必須的頭域。因為HTTP/1.0沒有定義任何1xx狀態碼，所以服務器不能發送一個1xx響應給一個HTTP/1.1客戶端，除了實驗性的目的。
客戶端必須能在一個常規響應之前接受一個或多個1xx狀態，即使客戶端不期望100（繼續）狀態響應。不被客戶端期望的1xx狀態響應可能會被用戶代理忽略。代理必須能轉發1xx響應，除非代理和它的客戶端的連接關閉了，或者除非代理自己響應請求並產生1xx響應。（例如：如果代理添加了“Expect:100-continue”頭域當轉發請求時，那么它
不必轉發相應的100（繼續）狀態響應。）
100狀態響應告訴客戶端應該繼續請求。100響應是個中間響應，它被用於通知客戶端請求的初始部分已經被接收了並且此請求還沒有被服務器丟棄。客戶端應該繼續發送請求的剩余部分，或者，如果此請求已經完成了客戶端會忽略此100響應。服務器在接收請求后必須發送一個終結響應。
服務器理解和願意遵循客戶端這樣的請求，此請求通過Upgrade消息頭域指明在連接上應用層協議的改變。 服務器將會切換到響應里Upgrade頭域里指明的協議，它會以一個空行結束此101響應。只有協議切換時能受益協議才應該切換。例如，當傳輸資源時，切換到一個新的HTTP版本比舊的版本要好，或者切換到一個實時的，同步的協議會帶來好處時，這時我們都應該考慮切換。
這類狀態碼指明客戶端的請球已經被服務器成功的接收，理解，並且接受了。
此狀態碼指明客戶端請求已經成功了。響應返回的信息依賴於請求里的方法，例如：
GET 請求資源的相應的實體已經包含在響應里並返回給客戶端。
HEAD 相應於請求資源實體的實體頭域已經被包含在無消息主體的響應里。
POST 響應里已經包含一個實體，此實體描述或者包含此POST動作執行的結果
TRACE 響應里包含一個實體，此實體包含終端對服務器接收的請求消息。
請求已經被服務器滿足了並且已經產生了一個新的資源。新創建的資源的URI在響應的實體里返回，但是此資源最精確的URI是在Location頭域里給出的。響應應該含有一實體，此實體包含此資源的特性和位置，用戶或用戶代理能從這些特性和位置里選擇最合適的。實體格式被Content-Type頭域里媒體類型指定。源服務器必須能在返回201狀態碼之前建立資源。如果動作（譯注：這里指能創建資源的方法，如POST方法）不能被立即執行，那么服務器應該以
202（接受）響應代替。一個201響應可以包含一個ETag響應頭域，此頭域的值指明了當前請求變量，也即剛剛創建的資源的實體標簽（entity tag）值。
請求已經被接受去處理，但是還沒有處理完成。請求可能會或者不會處理完成，因為存在當處理的過程中拒絕處理的情況。202響應是有意非擔保性的。它是為了允許服務器可以為其它處理（如：每天執行一次的批處理）接收請求而不需要用戶代理在處理沒有完成之前長期連接到服務器。響應里的實體應該包含請求當前狀態的聲明並且應該包含一個狀態監視指針或一些用戶期望何時請求被滿足的評估值。
此狀態碼響應指明響應里實體頭域元信息不能從源服務器獲而是從本地的或第三方響應副本里收集的。這些元信息可能是源服務器版本的子集或超集。如，包含一個存在本地的資源注釋信息就可以產生一個源服務器能理解的元信息的超集。利用此響應狀態碼不是必須但是比200（Ok）響應卻更加合適。
服務器已經滿足了請求但並沒有返回一個實體而是返回更新的元信息。此響應可能包含新的或更新的元信息以實體頭域的形式，這些元信息應該相關於請求變量。利用此204響應，客戶端如果是一個用戶代理，它就可以不用改變引起請求發送的文檔視圖。204狀態響應主要的目的是允許輸入，而不必引起用戶代理當前文檔視圖的改變，盡管一些新的或更新了的元信息可能會應用於用戶代理視圖里的當前文檔。204響應不能包含一個消息主體，並且在頭域后包含一個空行結束。
205狀態響應是服務器告訴用戶代理應該重置引起請求被發送的文檔視圖。此響應主要的目的是清空文檔視圖表單里的輸入框以便用戶能輸入其它信息。此響應不能包含一個實體。
服務器已經完成了客戶端對資源的部分GET請求。請求必須包含一個Range頭域用來指出想要的范圍，並且也有可能包含一個If-Range頭域來使請求成為一個條件請求。
206狀態的響應必須包含以下的頭域：
- 或者含有一個Content-Range 頭域，此頭域指明了響應里的范圍；或者含有一個值為“multipart/byteranges”的Content-Type頭域並且每部分包含Content-Range頭域。如果一個Content-Length頭域出現在響應里，它的值必須是實際傳輸的消息主體的字節數。
- Date頭域
- ETag 和/或 Content-Location頭域，如果這些頭域假設在相同請求的200響應里也會出現的話。
- Expire，Cache-Control，和/或者Vary頭域，如果這些頭域的域值與以前同一變量響應中的不一樣。
如果206響應是使用了強緩存驗證的If-Range請求的結果，那么此響應不應該包含其他的實體頭域。如果響應是使用了弱緩存驗證的If-Range請求的結果，那么響應必須不能包含其他的實體頭域；這能防止緩存里緩存的實體主體與更新頭域之間的不一致性。另外，響應必須包含假設在相同請求的200響應里的所有實體頭域。緩存不能把206響應和以前的緩存內容相合並如果ETag或Last-Modified頭域並不能精確匹配。一個不能支持Range和Content-Range頭域的緩存不能緩存206（部分的）響應。
這類狀態碼指明用戶代理需要更進一步的動作去完成請求。進一步的動作可能被用戶代理自動執行而不需要用戶的交互，並且進一步動作請求的方法必須為GET或HEAD。一個客戶端應該發現無限的重定向循環，因為此循環能產生網絡擁擠。注意：以前此規范版本建議一個最多能有五個重定向。內容開發者應該知道客戶端可能存在這個限制。
請求資源對應於眾多表現形式中的一個，每個表現形式都有一個特定的位置(location)，並且代理驅動協商（agent-driven negotiation）信息被提供以便用戶（或用戶代理）能選擇一個更適的表現形式並重定向它的請求那個表現形式的位置。除非是HEAD請求，否則300狀態響應應該包含一個實體，此實體包含一個資源特性和位置列表，從這個列表里用戶或用戶代理能選擇最合適的資源的表現形式。實體格式被Content-Type頭域里的媒體類型指定。用戶代理選擇最合適的表現形式的行為可能會被自動執行，這依賴於實體格式和自己的能力。然而，此規范並沒有定義自動執行行為的標准。如果服務器能確定更好的表現形式，它應該為此表現形式在Location頭域里包含一個特定的
URI來指明此表現形式的位置；用戶代理可能會利用此Location頭域自動重定向。300狀態響應是可緩存的除非被特別指明。
請求資源被賦於一個新的永久的URI，並且任何將來對此資源的引用都會利用此301狀態響應返回的URI。具有鏈接編輯能力的客戶端應該能自動把請求URI的引用轉到到服務器返回的新的引用下。此響應是能緩存的除非另外聲明。新的永久URI應該在響應中被Location頭域給定。除非請求方法是HEAD，否則此響應應該包含一個超文本提示和一個指向新URI的超文本鏈接。如果客戶端接收了一個來自非GET或HEAD請求方法的301響應，那么用戶代理不能自動重定向請求除非它能被用戶確認，因為這可能會改變請求提交的條件。
注意：當客戶端在接收了301 狀態碼響應后，會重定向POST 請求，一些已經存在的HTTP/1.0用戶代理會錯誤的把此請求變成一個GET請求。
請求的資源暫時地存放在一個不同的URI下。因為重定向的地址可能有時會被改變，客戶端應該繼續為將來的請求利用請求URI(Request-URI)。302響應是只有在Cache-Control或Expires頭域指明的情況下才能被緩存。臨時的URI應該在Location頭域里指定。除非請求方法是HEAD，否則此響應應該包含一個超文本提示和一個指向新URI的超文本鏈接。如果客戶端接收了一個來自非GET或HEAD請求方法的302響應，那么用戶代理不能自動重定向請求除非它能被用戶確認，因為這可能會改變請求提交的條件。
注意：RFC1945和RFC2068指定客戶端不能在重定向請求的時候改變請求方法。然而，大多數用戶代理實現會把302響應看成是303響應，從而根據Location頭域值的URI執行GET請求，不管原始的請求方法是什么。303和307狀態響應的目的是為使服務器明白客戶端期望哪種類型的重定向。
請求的響應被放在一個不同的URI下，並且應該用GET方法獲得那個資源。此方法的存在主要是讓POST調用腳本的輸出能使用戶代理重定向到一個選擇的資源。新的URI並不是原始請求資源的代替引用。303響應不能被緩存，但是再次重定向請求的響應應該被緩存。不同的URI應該在Location頭域里指定。除非請求方法是HEAD，除非請求方法是HEAD，否則此響應應該包含一個超文本提示和一個指向新URI的超文本鏈接。
注意：許多HTTP/1.1以前版本的用戶代理不能理解303狀態響應。當這些客戶端比較關注於互操作性的時候，302狀態碼應該被代替利用，因為大多用戶代理對302響應的理解就是303響應。
如果客戶端已經執行了條件GET請求，並且訪問服務器的資源是允許的，但是服務器上的文檔並沒有被改變，那么服務器應該以此狀態碼響應。304響應不能包含一個消息主體(messagebody)，並且在頭域后面總是以一個空行結束。此響應必須包含下面的頭域：
- Date，除非指明的那些規則下Date是可以遺漏的。如果時鍾不准確的源服務器遵循這些規則，並且代理和客戶端在接收了一個沒有Date頭域的響應后加上了自己的Date，緩存將會正確操作。
- ETag 和/或 Content-Location頭域，如果這些頭域應在相同請求的200響應里出現的話。
- Expire，Cache-Control，和/或者Vary頭域，如果這些頭域值與以前同一變量響應中的不一致。
如果條件GET請求使用強緩存驗證時，那么響應不應包含其它實體頭域。當條件GET使用弱緩存驗證時，那么響應必須不能包含其它實體頭域；這能防止緩存的實體主體與更新的頭域之間的不一致性。如果一個304響應指示一個沒有被緩存的實體，那么此緩存必須不用理會此響應，並且以無條件請求重試請求。如果緩存利用一個接收到的304響應去更新一個緩存項，那么緩存必須用此響應響應里任何最新的域值更新緩存項。
請求資源必須能通過代理訪問，代理的地址在響應的Location頭域里指定。Location頭域指定了代理的URI。接收者被期望通過代理重試此請求，305響應必須被源服務器產生。
注意：RFC 2068並沒有說明305響應必須重定向一個單獨請求並且只能被源服務器產生。不注意這些限制會有重要的安全后果。
306狀態碼被用於此規范以前的版本，是不再使用的意思，並且此狀態碼被保留。
請求的資源臨時存在於一個不同的URI下。由於重新向可能有時會改變，所以客戶端應該繼續利用此請URI（Request-URI）為將來的請求。307響應只有被Cache-Control或Expire頭域指明時才能被緩存。臨時URI應該在響應的Location頭域里給定。否則此響應應該包含一個超文本提示和一個指向新URI的超文本鏈接，因為許多HTTP/1.1以前的用戶代理不能理解307狀態響應。因此，此提示應該包含用戶在新的URI上重試原始請求的必需信息。如果307狀態響應.對應的請求的方法不是GET或HEAD，那么用戶代理不能自動重定向此請求除非它能被用戶確認，因為因為這可能會改變請求提交的條件。
狀態碼4xx類的目的是為了指明客戶端出現錯誤的情況。除了當響應一個HEAD請求，服務器應該包含一個實體，此實體包含一個此錯誤請求的解釋。此狀態碼對所有請求方法都是適合的。用戶代理應該展示任何響應里包含的實體給用戶。如果客戶端發送數據，利用TCP的服務器實現應該小心地確保客戶端確認包含了響應的包（packets）的接收，在服務器關閉此輸入連接前。如果在關閉連接后，客戶端繼續發送數據給服務器，那么服務器的TCP棧將發送一個重置包給客戶端，這能擦除客戶端非確認的輸入緩沖（input buffers）在這些緩沖被HTTP應用程序讀和解析之前。
請求不能被服務器理解，由於錯誤的語法。客戶端不應該在沒有改變請求的情況下重試請求。
服務器需要對請求進行用戶認證。響應必須包含一個WWW-Authenticate頭域，此頭域包含一個適用於請求資源的授權的激勵（challenge）。客戶端會以一個Authorization頭域重試請求。如果請求包含了授權證書，那么401響應指明對這些證書的授權失敗。如果401響應包含一個和以前響應的同樣激勵，並且用戶代理已經嘗試至少一次的授權，那么用戶應該被呈現包含在響應里的實體，因為這些實體可能包含相關的診斷信息。
此狀態碼為將來的應用保留。
服務器理解此請求，但拒絕滿足此請求。認證是沒有作用的，並且請求不應該被重試。如果請求方法是HEAD並且服務器想讓客戶端知道請求為什么不能被滿足，那么服務器起應該在響應實體里描述此拒絕的原因。如果服務器不希望告訴客戶端拒絕的原因，那么404 狀態碼(NotFound)響應將被使用。
服務器並沒有找到任何可以匹配請求URI 的資源。沒有跡象表明條件是暫時或永久的。
410（Gone）狀態響應應該被使用，如果服務器通過內部配置機制知道一個舊資源永遠不能獲得並且也沒有轉發地址。此狀態碼通常被使用，當服務器不希望精確指出請求為何被拒絕，或
者當沒有任何其它響應可用時。
此狀態碼表示請求行（Request-Line）里的方法對此資源來說不被允許。響應必須包含一個
Allow頭域，此頭域包含以一系列對此請求資源有效的方法。
根據客戶端請求的接受頭域（譯注：如：Accept, Accept-Charset, Accept-Encoding, 或者 Accept-Language），服務器不能產生讓客戶端可以接受的響應。除非是HEAD請求，否則響應應該包含一個實體，此實體應該包含一個可得的實體特性和位置列表，通過它用戶或用戶代理能選擇最合適自己的。實體格式被媒體類型指定。依賴於此格式和用戶代理的本身能力，選擇最合適的可能會被自動執行。然而，此規范並沒有定義自動執行選擇的標准。
注意：HTTP/1.1服務器被准許根據請求里的接受頭域會返回不可接受的響應。在一些情況下，這可能更傾向於發送一個406響應。用戶代理被鼓勵觀察到來的響應的頭域來確定此響應是否是可接受的。如果響應是不可接受的，用戶代理應該暫時停止剩余數據的接收並且詢問用戶然后去決定進一步的動作。
此狀態碼和401（Unauthorized）相似，但是指示客戶端首先必須利用代理對自己驗證。代理必須返回一個Proxy-Authenticate頭域，此頭域包含一個適用於代理的授權激勵。客戶端可能利用一個合適的Proxy-Autorization頭域去重試此請求。
客戶端在服務器等待的時間里不能產生請求。客戶端可能在以后會重試此請求。
請求不能完成由於和當前資源的狀態沖突。此狀態碼只被允許出現在期望用戶也許能解決此沖並且能重新提交此請求的情況下。響應主體應該包含足夠的為用戶認識此資源沖突的信息。理想的情況下，響應實體應該包含足夠為用戶或用戶代理解決此問題的信息；然而，這是也許沒有可能並且也沒有必要。沖突最可能發生在響應PUT請求的時候。例如，如果版本被使用並且被PUT的實體包含資源的改變，而這些改變會和以前的（第三方的）請求的相沖突，那么服務器應該使用409響應去指明它不能完成此請求。在這種情況下，此響應的實體可能包含這兩個版本的差異點，響應的實體格式以Content-Type頭域指定。
請求資源在源服務器上不再可得並且也沒有轉發地址可用。此條件被認為是永久的。具有鏈接編輯能力的客戶端應該在用戶確認后刪除請求URI的引用。如果服務器不知道或不容易去確定條件是否是永久的，那么此404（沒有發現）狀態響應將被代替利用。響應是可緩存的，除非另外申明。
410響應主要的目的是為了web維護任務，這通過告訴接收者資源已經不可得了並且告訴接收者服務器擁有者已經把那個資源的遠程連接給移除了。對有時間限制的，推銷性的服務，和對不再繼續工作在服務器站點人員的資源，這個事件（410響應）是非常普遍的。它不需要把所有長久不可得的資源標記為“gone”或者保持任意長時間—這需要服務器擁有者自己的判斷
服務器拒絕接受請求里沒有包含Content-Length頭域的請求。客戶端可以重試此請求如果它添加了一個有效的Content-Length頭域，此頭域值指定了請求消息里消息主體的長度。
在一個或多個請求頭域里指定的先決條件當在服務器上測試為false時返回的響應。此響應允許客戶端把先決條件放放到當前資源的元信息（頭域數據）之上，這樣能防止請求方法被應用於一個非目的性的資源。
服務器拒絕處理請求因為請求實體太大以致達到服務器不願意去處理。服務器可能關閉此連接去防止客戶端繼續請求。如果條件是暫時的，服務器應該包含一個Retry-After頭域用來指明此條件是暫時的並且指明客戶端應該什么時候重試。
服務器拒絕為請求服務因為此請求URI太長了以至於服務器不能解析。這種情況是很少的，只發生在當客戶端POST請求不合適地轉換為帶有大量查詢信息的GET請求時。
服務器拒絕為請求服務，因為請求的實體的格式不能被此方法的請求資源所支持。
服務器返回一個此狀態碼的響應，如果請求包含一個Range請求頭域，並且此頭域里range-specifier值沒有和已選資源的當前extent值重疊，並且請求沒有包含一個If-Range請求頭域。（對byte-ranges來說，這意味着byte-range-spec的所有first-byte-pos值大於選擇的資源的當前長度）。當此狀態碼響應是在byte-range請求返回時，響應應該包含一個Content-Range實體頭域用來指定已選資源的當前長度。響應不能使用multipart/byteranges媒體類型。
Expect請求頭域里指定的希望不能被服務器滿足，或者，如果服務器是代理，那么能確定請求不能被下一站（next-hop）服務器滿足。
這類狀態碼指明服務器處理請求時產生錯誤或不能處理請求。除了HEAD請求，服務器應該包含一個實體，此實體用來解釋錯誤，和是否是暫時或長期條件。用戶代理應該展示實體給用戶。此響應狀態碼能應用於任何請求方法。
服務器遇到了一個意外條件，此條件防止服務器滿足此請求。
服務器沒有能力去滿足請求。當服務器不能識別請求方法並且不支持它請求資源的時候，這個響應是很合適的。
此響應說明：作為網關或代理的服務器從上游（upstream）服務器接收了一個無效的響應。
由於服務器暫時地過載或維護，服務器不能處理請求。這就是說這是暫時條件，此條件將會在一些延時后被減輕。延遲的長度可以在Retry-After頭域里指定。如果沒有Retry-After被給，那么客戶端應該處理此響應就像它處理500響應一樣。
注意：503狀態碼的存在並不是意指服務器當產生過載時必須利用它。一些服務器可能希望拒絕此連接。
作為網關或代理的服務器在不能及時地接收一個從URI指定的上游（upstream）服務器（例如：HTTP，FTP，LDAP服務器）或者其他的輔助性服務器（例如：DNS服務器）的響應。
注意：當DNS查找超時時，一些部署的代理將會返回400或500響應。
服務器不能支持，或拒絕支持此HTTP協議版本消息。505響應指明服務器不能或不願意完成這樣的請求。此響應應該包含一個實體，此實體描述了為什么此協議版本不被支持和其他能被服務器支持的協議版本。