HTTP 狀態碼負責表示客戶端 HTTP 請求的返回結果、標記服務器端 的處理是否正常、通知出現的錯誤等工做。瀏覽器
響應的狀態碼可描述請求的處理結果,狀態碼如 200 OK,以 3 位數字和緣由短語組成。服務器
數字中的第一位指定了響應類別,後兩位無分類。響應類別有如下 5 種。cdn
只要遵照狀態碼類別的定義,即便改變 RFC2616 中定義的狀態碼, 或服務器端自行建立狀態碼都沒問題。blog
2XX 的響應結果代表請求被正常處理了。資源
表示從客戶端發來的請求在服務器端被正常處理了。 在響應報文內,隨狀態碼一塊兒返回的信息會因方法的不一樣而發生改 變。好比,使用 GET 方法時,對應請求資源的實體會做爲響應返 回;而使用 HEAD 方法時,對應請求資源的實體首部不隨報文主體 做爲響應返回(即在響應中只返回首部,不會返回實體的主體部 分)。it
該狀態碼錶明服務器接收的請求已成功處理,但在返回的響應報文中 不含實體的主體部分。另外,也不容許返回任何實體的主體。好比, 當從瀏覽器發出請求處理後,返回 204 響應,那麼瀏覽器顯示的頁面 不發生更新。 通常在只須要從客戶端往服務器發送信息,而對客戶端不須要發送新信息內容的狀況下使用。io
該狀態碼錶示客戶端進行了範圍請求,而服務器成功執行了這部分的 GET 請求。響應報文中包含由 Content-Range 指定範圍的實體內容。class
3XX 響應結果代表瀏覽器須要執行某些特殊的處理以正確處理請 求。服務器端
永久性重定向。該狀態碼錶示請求的資源已被分配了新的 URI,之後 應使用資源如今所指的 URI。也就是說,若是已經把資源對應的 URI 保存爲書籤了,這時應該按 Location 首部字段提示的 URI 從新保存。 像下方給出的請求 URI,當指定資源路徑的最後忘記添加斜槓「/」,就 會產生 301 狀態碼。權限
臨時性重定向。該狀態碼錶示請求的資源已被分配了新的 URI,但願 用戶(本次)能使用新的 URI 訪問。 和 301 Moved Permanently 狀態碼類似,但 302 狀態碼錶明的資源不 是被永久移動,只是臨時性質的。換句話說,已移動的資源對應的 URI 未來還有可能發生改變。好比,用戶把 URI 保存成書籤,但不會 像 301 狀態碼出現時那樣去更新書籤,而是仍舊保留返回 302 狀態碼 的頁面對應的 URI。
該狀態碼錶示因爲請求對應的資源存在着另外一個 URI,應使用 GET 方法定向獲取請求的資源。
當 30一、30二、303 響應狀態碼返回時,幾乎全部的瀏覽器都會把 POST 改爲 GET,並刪除請求報文內的主體,以後請求會自動再次 發送。 30一、302 標準是禁止將 POST 方法改變成 GET 方法的,但實際使 用時你們都會這麼作。
該狀態碼錶示客戶端發送附帶條件的請求 2 時,服務器端容許請求訪 問資源,但未知足條件的狀況。304 狀態碼返回時,不包含任何響應 的主體部分。304 雖然被劃分在 3XX 類別中,可是和重定向沒有關 系。 附帶條件的請求是指採用 GET 方法的請求報文中包含 If-Match,If-ModifiedSince,If-None-Match,If-Range,If-Unmodified-Since 中任一首部。
臨時重定向。該狀態碼與 302 Found 有着相同的含義。儘管 302 標準禁止 POST 變換成 GET,但實際使用時你們並不遵照。 307 會遵守瀏覽器標準,不會從 POST 變成 GET。可是,對於處理響 應時的行爲,每種瀏覽器有可能出現不一樣的狀況。
該狀態碼錶示請求報文中存在語法錯誤。當錯誤發生時,需修改請求 的內容後再次發送請求。另外,瀏覽器會像 200 OK 同樣對待該狀態 碼。
該狀態碼錶示發送的請求須要有經過 HTTP 認證(BASIC 認證、 DIGEST 認證)的認證信息。另外若以前已進行過 1 次請求,則表示 用 戶認證失敗。 返回含有 401 的響應必須包含一個適用於被請求資源的 WWWAuthenticate 首部用以質詢(challenge)用戶信息。當瀏覽器初次接收 到 401 響應,會彈出認證用的對話窗口。
該狀態碼代表對請求資源的訪問被服務器拒絕了。服務器端沒有必要 給出拒絕的詳細理由,但若是想做說明的話,能夠在實體的主體部分對緣由進行描述,這樣就能讓用戶看到了。 未得到文件系統的訪問受權,訪問權限出現某些問題(從未受權的發 送源 IP 地址試圖訪問)等列舉的狀況均可能是發生 403 的緣由。
該狀態碼代表服務器上沒法找到請求的資源。除此以外,也能夠在服 務器端拒絕請求且不想說明理由時使用。
該狀態碼代表服務器端在執行請求時發生了錯誤。也有多是 Web 應用存在的 bug 或某些臨時的故障。
該狀態碼代表服務器暫時處於超負載或正在進行停機維護,如今沒法 處理請求。若是事先得知解除以上情況須要的時間,最好寫入 RetryAfter 首部字段再返回給客戶端。
狀態碼和情況的不一致 很多返回的狀態碼響應都是錯誤的,可是用戶可能察覺不到這點。 好比 Web 應用程序內部發生錯誤,狀態碼依然返回 200 OK,這種 狀況也常常遇到。