【網絡】http狀態碼

狀態碼	緣由短語	表明含義	HTTP 版本
狀態碼	緣由短語	表明含義	HTTP 版本
消息響應
100	Continue (繼續)	客戶端應當繼續發送請求.這個臨時響應是用來通知客戶端它的部分請求已經被服務器接收,且仍未被拒絕.客戶端應當繼續發送請求的剩餘部分,或者若是請求已經完成,忽略這個響應.服務器必須在請求完成後向客戶端發送一個最終響應.	HTTP/1.1 可用
101	Switching Protocol (切換協議)	服務器已經理解了客戶端的請求，並將經過Upgrade消息頭通知客戶端採用不一樣的協議來完成這個請求。在發送完這個響應最後的空行後，服務器將會切換到 在Upgrade消息頭中定義的那些協議。: 只有在切換新的協議更有好處的時候才應該採起相似措施。例如，切換到新的HTTP版本比舊版本更有優點，或者切換到一個實時且同步的協議以傳送利用此類特 性的資源。	HTTP/1.1 可用
成功響應
200	OK (成功)	請求成功.成功的意義根據請求所使用的方法不一樣而不一樣. · GET: 資源已被提取,並做爲響應體傳回客戶端. · HEAD: 實體頭已做爲響應頭傳回客戶端 · POST: 通過服務器處理客戶端傳來的數據,適合的資源做爲響應體傳回客戶端. · TRACE: 服務器收到請求消息做爲響應體傳回客戶端. PUT, DELETE, 和 OPTIONS 方法永遠不會返回 200 狀態碼.	HTTP/0.9 可用
201	Created (已建立)	請求成功，並且有一個新的資源已經依據請求的須要而創建，一般這是 PUT 方法獲得的響應碼.	HTTP/0.9 可用
202	Accepted (已建立)	服務器已接受請求，但還沒有處理。正如它可能被拒絕同樣，最終該請求可能會也可能不會被執行。在異步操做的場合下，沒有比發送這個狀態碼更方便的作法了。:返回202狀態碼的響應的目的是容許服務器接受其餘過程的請求（例如某個天天只執行一次的基於批處理的操做），而沒必要讓客戶端一直保持與服務器的鏈接直到批處理操做所有完成。在接受請求處理並返回202狀態碼的響應應當在返回的實體中包含一些指示處理當前狀態的信息，以及指向處理狀態監視器或狀態預測的指針，以便用戶可以估計操做是否已經完成。	HTTP/0.9 可用
203	Non-Authoritative Information (未受權信息)	服務器已成功處理了請求,但返回的實體頭部元信息不是在原始服務器上有效的肯定集合，而是來自本地或者第三方的拷貝,若是不是上述狀況,使用200狀態碼纔是最合適的.	HTTP/0.9 and 1.1
204	No Content (無內容)	該響應沒有響應內容,只有響應頭,響應頭也多是有用的.用戶代理能夠根據新的響應頭來更新對應資源的緩存信息.	HTTP/0.9 可用
205	Reset Content (重置內容)	告訴用戶代理去重置發送該請求的窗口的文檔視圖.	HTTP/1.1 可用
206	Partial Content (部份內容)	當客戶端經過使用range頭字段進行文件分段下載時使用該狀態碼	HTTP/1.1 可用
重定向
300	Multiple Choice (多種選擇)	該請求有多種可能的響應,用戶代理或者用戶必須選擇它們其中的一個.服務器沒有任何標準能夠遵循去代替用戶來進行選擇.	HTTP/1.0 and later
301	Moved Permanently (永久移動)	該狀態碼錶示所請求的URI資源路徑已經改變,新的URL會在響應的Location:頭字段裏找到.	HTTP/0.9 可用
302	Found (臨時移動)	該狀態碼錶示所請求的URI資源路徑臨時改變,而且還可能繼續改變.所以客戶端在之後訪問時還得繼續使用該URI.新的URL會在響應的Location:頭字段裏找到.	HTTP/0.9 可用
303	See Other (查看其餘位置)	服務器發送該響應用來引導客戶端使用GET方法訪問另一個URI.	HTTP/0.9 and 1.1
304	Not Modified (未修改)	告訴客戶端,所請求的內容距離上次訪問並無變化. 客戶端能夠直接從瀏覽器緩存裏獲取該資源.	HTTP/0.9 可用
305	Use Proxy (使用代理)	所請求的資源必須統過代理才能訪問到.因爲安全緣由,該狀態碼並未受到普遍支持.	HTTP/1.1 可用
306	unused (未使用)	這個狀態碼已經再也不被使用,當初它被用在HTTP 1.1規範的舊版本中.	HTTP/1.1 可用
307	Temporary Redirect (臨時重定向)	服務器發送該響應用來引導客戶端使用相同的方法訪問另一個URI來獲取想要獲取的資源.新的URL會在響應的Location:頭字段裏找到.與302狀態碼有相同的語義,且先後兩次訪問必須使用相同的方法(GET POST).	HTTP/1.1 可用
308	Permanent Redirect (永久重定向)	所請求的資源將永久的位於另一個URI上.新的URL會在響應的Location:頭字段裏找到.與301狀態碼有相同的語義,且先後兩次訪問必須使用相同的方法(GET POST).	HTTPbis (試驗草案)
客戶端錯誤
400	Bad Request (錯誤請求)	因發送的請求語法錯誤,服務器沒法正常讀取.	HTTP/0.9 可用
401	Unauthorized (未受權)	須要身份驗證後才能獲取所請求的內容,相似於403錯誤.不一樣點是.401錯誤後,只要正確輸入賬號密碼,驗證便可經過.	HTTP/0.9 可用
402	Payment Required (須要付款)	該狀態碼被保留以供未來使用.建立此代碼最初的目的是爲數字支付系統而用,然而,到如今也沒投入使用.	HTTP/0.9 and 1.1
403	Forbidden (禁止訪問)	客戶端沒有權利訪問所請求內容,服務器拒絕本次請求.	HTTP/0.9 可用
404	Not Found (未找到)	服務器找不到所請求的資源.因爲常常發生此種狀況,因此該狀態碼在上網時是很是常見的.	HTTP/0.9 可用
405	Method Not Allowed (不容許使用該方法)	該請求使用的方法被服務器端禁止使用,RFC2616中規定, GET 和 HEAD 方法不能被禁止.	HTTP/1.1 可用
406	Not Acceptable (沒法接受)	在進行服務器驅動內容協商後,沒有發現合適的內容傳回給客戶端.	HTTP/1.1 可用
407	Proxy Authentication Required (要求代理身份驗證)	相似於狀態碼 401,不過須要經過代理才能進行驗證.	HTTP/1.1 可用
408	Request Timeout (請求超時)	客戶端沒有在服務器預備等待的時間內完成一個請求的發送.這意味着服務器將會切斷和客戶端的鏈接. 在其餘瀏覽器中,這種響應更常見一些, 例如Chrome 和 IE9, 目的是爲了使用HTTP 預連機制加快瀏覽速度. 同時注意,一些服務器不發送此種響應就直接切斷鏈接.	HTTP/1.1 可用
409	Conflict (衝突)	該請求與服務器的當前狀態所衝突.	HTTP/1.1 可用
410	Gone (已失效)	所請求的資源已經被刪除.	HTTP/1.1 可用
411	Length Required (須要內容長度頭)	因服務器在本次請求中須要 Content-Length 頭字段,而客戶端沒有發送.因此,服務器拒絕了該請求.	HTTP/1.1 可用
412	Precondition Failed (預處理失敗)	服務器沒能知足客戶端在獲取資源時在請求頭字段中設置的先決條件.	HTTP/1.1 可用
413	Request Entity Too Large (請求實體過長)	請求實體大小超過服務器的設置的最大限制,服務器可能會關閉HTTP連接並返回Retry-After 頭字段.	HTTP/1.1 可用
414	Request-URI Too Long (請求網址過長)	客戶端請求所包含的URI地址太長,以致於服務器沒法處理.	HTTP/1.1 可用
415	Unsupported Media Type (媒體類型不支持)	服務器不支持客戶端所請求的媒體類型,所以拒絕該請求.	HTTP/1.1 可用
416	Requested Range Not Satisfiable (請求範圍不合要求)	請求中包含的Range頭字段沒法被知足,一般是由於Range中的數字範圍超出所請求資源的大小.	HTTP/1.1 可用
417	Expectation Failed (預期結果失敗)	在請求頭 Expect 中指定的預期內容沒法被服務器知足.	HTTP/1.1 可用
服務器端錯誤
500	Internal Server Error (內部服務器錯誤)	服務器遇到未知的沒法解決的問題.	HTTP/0.9 可用
501	Implemented (未實現)	服務器不支持該請求中使用的方法,好比POST 和 PUT.只有GET 和 HEAD 是RFC2616規範中規定服務器必須實現的方法.	HTTP/0.9 可用
502	Bad Gateway (網關錯誤)	服務器做爲網關且從上游服務器獲取到了一個無效的HTTP響應.	HTTP/0.9 可用
503	Service Unavailable (服務不可用)	因爲臨時的服務器維護或者過載,服務器當前沒法處理請求.這個情況是臨時的,而且將在一段時間之後恢復.若是可以預計延遲時間,那麼響應中能夠包含一個Retry-After:頭用以標明這個延遲時間.若是沒有給出這個Retry-After:信息，那麼客戶端應當以處理500響應的方式處理它.同時,這種狀況下,一個友好的用於解釋服務器出現問題的頁面應當被返回,而且,緩存相關的HTTP頭信息也應該包含,由於一般這種錯誤提示網頁不該當被客戶端緩存.	HTTP/0.9 可用
504	Gateway Timeout (網關超時)	服務器做爲網關且不能從上游服務器及時的獲得響應返回給客戶端.	HTTP/1.1 可用
505	HTTP Version Not Supported (HTTP版本不受支持)	服務器不支持客戶端發送的HTTP請求中所使用的HTTP協議版本.	版本判斷
500	Internal Server Error (內部服務器錯誤)	服務器遇到未知的沒法解決的問題.	HTTP/0.9 可用
501	Implemented (未實現)	服務器不支持該請求中使用的方法,好比POST 和 PUT.只有GET 和 HEAD 是RFC2616規範中規定服務器必須實現的方法.	HTTP/0.9 可用
502	Bad Gateway (網關錯誤)	服務器做爲網關且從上游服務器獲取到了一個無效的HTTP響應.	HTTP/0.9 可用
503	Service Unavailable (服務不可用)	因爲臨時的服務器維護或者過載,服務器當前沒法處理請求.這個情況是臨時的,而且將在一段時間之後恢復.若是可以預計延遲時間,那麼響應中能夠包含一個Retry-After:頭用以標明這個延遲時間.若是沒有給出這個Retry-After:信息，那麼客戶端應當以處理500響應的方式處理它.同時,這種狀況下,一個友好的用於解釋服務器出現問題的頁面應當被返回,而且,緩存相關的HTTP頭信息也應該包含,由於一般這種錯誤提示網頁不該當被客戶端緩存.	HTTP/0.9 可用
504	Gateway Timeout (網關超時)	服務器做爲網關且不能從上游服務器及時的獲得響應返回給客戶端.	HTTP/1.1 可用
505	HTTP Version Not Supported (HTTP版本不受支持)	服務器不支持客戶端發送的HTTP請求中所使用的HTTP協議版本.	版本判斷