| HTTP 狀態碼 | 狀態碼的含義 |
|---|---|
| 100 | 客戶端仍應發送請求。 此臨時回應用於通知客戶端請求的一部分已被伺服器接收且尚未被拒絕。 客戶端應該繼續發送請求的其餘部分，或在請求完成時忽略回應。 完成請求後，伺服器應向客戶端發送最終回應。 |
| 101 | 伺服器理解客戶端的請求，並透過Upgrade訊息標頭通知客戶端使用不同的協定來完成請求。 發送此回應的最後一個空白行後，伺服器切換到升級訊息標頭中定義的協定。 只有在切換到新協議更有利時，才應執行類似的程序。 例如，切換到較新的 HTTP 版本比舊版本具有優勢。 或者，切換到即時和同步協定來傳輸使用此類功能的資源。 |
| 102 | 由 WebDAV (RFC 2518) 擴充的狀態代碼指示處理應該繼續。 |
| 200 | 請求成功。 請求的回應標頭或資料主體與此回應一起傳回。 |
| 201 | 請求已完成，已根據請求建立新資源，其 URI 已與 Location 標頭一起傳回。 如果無法及時建立所需的資源，則必須返回"202 已接受"。 |
| 202 | 伺服器已接受請求但尚未處理。 一個請求最終可能會或可能不會被滿足，就像它可能被拒絕一樣。 對於異步操作，除了發送這個狀態碼之外沒有方便的方法。 傳回 202 狀態代碼的回應的目的是允許伺服器接受來自其他進程的請求（例如每天只運行一次的基於批次的操作）。 批量操作完成。 接受處理請求並傳回 202 狀態代碼的回應必須在傳回的實體中包含指示處理目前狀態的資訊以及指向處理狀態監視器或狀態預測的指標。 操作完成。 |
| 203 | 伺服器成功處理了請求，但傳回的實體頭元資訊是來自本地或第三方的副本，而不是在原始伺服器上有效的確定性集合。 當前資訊可能是原始版本的子集或超集。 例如，包括資源的元資料可能允許來源伺服器識別元資料。 無需使用此狀態代碼。 僅當回應中未使用此狀態代碼時才傳回 200。 情況還可以。 |
| 204 | 伺服器成功處理了請求，但它不需要傳回實體內容，它想傳回更新後的元資訊。 回應可能會以實體標頭的形式傳回新的或更新的元資訊。 如果存在這些標頭，則它們必須對應於請求的變數。 如果用戶端是瀏覽器，即使新的或更新的元資訊需要應用到使用者的瀏覽器活動文件視圖中，使用者的瀏覽器會在不改變文件視圖的情況下呈現請求的頁面。 禁止 204 回應包含訊息正文，因此它始終以訊息標頭後的第一個空白行結束。 |
| 205 | 伺服器成功處理了請求並且沒有傳回任何內容。 但是，與 204 回應不同，傳回此狀態代碼的回應需要請求者重設文件視圖。 此回應主要用於在接受使用者輸入後立即重置表單，以便使用者可以輕鬆地開始另一個輸入。 與 204 回應一樣，回應也被禁止包含訊息正文，以訊息標頭後的第一個空白行結束。 |
| 206 | 伺服器成功處理了一些 GET 請求。 FlashGet、迅雷等HTTP下載工具就是利用這種回應來實現斷點重啟或將大檔案拆分成多個下載段同時下載。 此請求必須包含一個 Range 標頭，指示客戶端想要的內容範圍，並且可以包含 If-Range 作為請求條件。 回應必須包含以下標頭欄位： Content-Range 用於表示本次回應傳回的內容範圍。 對於具有多部分/字節範圍 Content-Type 的多段下載，每個多部分段必須包含一個 Content-Range 域，用於指示該段落的範圍。 如果回應中包含 Content-Length，則其值應與傳回內容範圍內的實際字節數相符。 日期 ETag 和/或內容位置（如果相同的請求應傳回 200 回應）。 Expires、Cache-Control 和/或 Vary 值可能與同一變數的其他先前回應中的對應值不同。 如果此回應請求使用 If-Range 強快取驗證，請不要在此回應中包含任何其他實體標頭。 如果此回應請求使用 If-Range 弱快取驗證，則此回應不得包含任何其他實體標頭。 這避免了快取的實體內容和更新的實體頭資訊之間的不一致。 否則，此回應必須包含應在 200 回應中傳回的所有實體標頭欄位。 如果 ETag 或 Last-Modified 標頭不完全匹配，用戶端快取應避免將 206 回應傳回的內容與先前快取的內容組合。 禁止不支援 Range 和 Content-Range 標頭的快取快取 206 回應傳回的內容。 |
| 207 | 由 WebDAV (RFC 2518) 擴展的狀態代碼表示後續的訊息主體將是一個 XML 訊息，並且可能包含一系列獨立的回應代碼，具體取決於先前的子請求的數量。 |
| 300 | 請求的資源有一組可選的回饋訊息，每一個都有一個唯一的位址和瀏覽器驅動的協商資訊。 使用者或瀏覽器可以選擇首選地址進行重定向。 除非這是 HEAD 請求，否則回應應該包含一個包含資源特徵和位址清單的實體，使用者或瀏覽器可以從中選擇最合適的重新導向位址。 實體的格式由 Content-Type 中定義的格式決定。 瀏覽器可能會根據回應的格式和瀏覽器本身的功能自動做出最合適的選擇。 當然，RFC 2616 規範並沒有指定這種自動選擇應該如何進行。 如果伺服器本身已經有一個首選的回饋選項，那麼 Location URI 應該在 Location 中指定。 瀏覽器可以使用這個 Location 值作為自動重定向的位址。 除非另有說明，否則此回應也是可快取的。 |
| 301 | 請求的資源已移動到一個全新的位置。 以後對該資源的引用應使用此回應中傳回的多個 URI 之一。 如果可能，具有連結編輯功能的用戶端應自動將請求的位址變更為伺服器傳回的位址。 除非另有說明，否則此回應也是可快取的。 應在回應的 Location 欄位中傳回新的永久 URI。 除非這是一個 HEAD 請求，否則回應實體應該包含指向新 URI 的超連結和簡短描述。 如果這不是 GET 或 HEAD 請求，請求的條款可能會相應更改，因此瀏覽器不會自動重定向，除非使用者確認。 注意：在某些使用 HTTP/1.0 協定的瀏覽器中，向 POST 請求發送 301 回應將導致下一個重新導向請求的 GET。 |
| 302 | 請求的資源現在臨時回應來自另一個 URI 的請求。 此重定向是暫時的，客戶端應繼續向原始位址發送請求。 此回應僅在由 Cache-Control 或 Expires 指定時才可快取。 應在回應的 Location 欄位中傳回新的臨時 URI。 除非這是一個 HEAD 請求，否則回應實體應該包含指向新 URI 的超連結和簡短描述。 如果這不是 GET 或 HEAD 請求，請求的條款可能會相應更改，因此瀏覽器將不允許自動重定向，除非使用者確認。 注意：雖然RFC 1945 和RFC 2068 規範不允許客戶端在重定向期間更改請求的方法，但許多現有瀏覽器將302 響應視為303 響應，並且無論位置如何，都使用GET 訪問Location 指定的URI 。 URI。 最初請求的方法。 新增狀態代碼 303 和 307 以闡明伺服器期望客戶端執行的操作。 |
| 303 | 對應於當前請求的回應可以在另一個 URI 中找到，客戶端應該使用 GET 來詢問該資源。 此方法的存在主要是為了允許將腳本啟動的 POST 請求的輸出重定向到新資源。 這個新的 URI 不是對原始資源的替代引用。 同時禁止緩存303響應。 當然你也可以快取第二個請求（重定向）。 應在回應的 Location 欄位中傳回新的 URI。 除非這是一個 HEAD 請求，否則回應實體應該包含指向新 URI 的超連結和簡短描述。 注意：許多 HTTP/1.1 之前的瀏覽器無法正確辨識 303 狀態。 如果您關心與這些瀏覽器的交互，302 狀態代碼就足夠了。 這是因為大多數瀏覽器處理 302 回應的方式與客戶端在處理上述規範中的 303 回應時應該做的完全一樣。 |
| 304 | 如果用戶端發送了一個有條件的 GET 請求，請求被授予，且文件內容沒有改變（自上次訪問以來或根據請求的條件），伺服器應該傳回此狀態代碼。 禁止 304 回應包含訊息正文，因此它始終以訊息標頭後的第一個空白行結束。 回應應包含以下標頭：日期，除非此伺服器沒有時鐘。 如果無時鐘伺服器也遵守這些規則，代理伺服器和用戶端可以在收到的回應頭中新增一個日期欄位（根據 RFC）。 2068)，快取機制運作正常。 ETag 和/或 Content-Location（如果相同的請求應傳回 200 個回應）。 Expires、Cache-Control 和/或 Vary 值可能與同一變數的其他先前回應中的對應值不同。 如果此回應請求使用強快取身份驗證，請不要在此回應中包含任何其他實體標頭。 否則（例如，如果條件 GET 請求使用弱快取身份驗證），則禁止在此回應中包含其他實體標頭。 這避免了快取的實體內容和更新的實體頭資訊之間的不一致。 如果 304 回應表示該實體目前未被緩存，則快取系統應忽略該回應並重複發送不包含限制的請求。 當收到要求更新快取條目的 304 回應時，快取系統必須更新整個條目以反映回應中所有欄位的更新值。 |
| 305 | 請求的資源必須可以透過指定的代理訪問。 Location 欄位伴供指定代理的 URI 資訊。 接收者必須重複發送另一個請求才能通過此代理訪問相應的資源。 只有來源伺服器才能建立 305 回應。 注意：RFC 2068 沒有針對重定向單一請求的顯式 305 回應，它只能由來源伺服器建立。 忽略這些限制可能會導致嚴重的安全後果。 |
| 306 | 最新版本的規格不再使用 306 狀態碼。 |
| 307 | 請求的資源現在臨時回應來自另一個 URI 的請求。 此重定向是暫時的，客戶端應繼續向原始位址發送請求。 此回應僅在由 Cache-Control 或 Expires 指定時才可快取。 應在回應的 Location 欄位中傳回新的臨時 URI。 除非這是一個 HEAD 請求，否則回應實體應該包含指向新 URI 的超連結和簡短描述。 有些瀏覽器無法理解 307 回應，因此您需要在上面新增必要的訊息，以便使用者能夠理解並發出訪問新 URI 的請求。 如果這不是 GET 或 HEAD 請求，請求的條款可能會相應更改，因此瀏覽器將不允許自動重定向，除非使用者確認。 |
| 400 | 1.語義不正確，伺服器無法理解目前請求。 除非更改，否則客戶端不得重複發送此請求。 2、請求參數錯誤。 |
| 401 | 當前請求需要使用者身份驗證。 回應必須包含適合所請求資源的 WWW-Authenticate 標頭，以瞭解使用者輸入資訊。 客戶端可以重複發送帶有適當授權標頭的請求。 如果目前請求已經包含身分驗證證書，則 401 回應表示伺服器已確認這些證書已被拒絕。 如果 401 回應包含與先前回應相同的身份驗證質詢，且瀏覽器至少嘗試過一次身份驗證，則瀏覽器應向使用者顯示回應中包含的實體資訊。 這是因為這個實體資訊可能包含相關的診斷資訊。 參見 RFC 2617. |
| 402 | 此狀態代碼保留供將來需要。 |
| 403 | 伺服器理解請求但拒絕執行它。 與 401 回應不同，身份驗證不會以任何方式幫助您，所以不要重新發送此請求。 如果這不是 HEAD 請求，並且您希望伺服器能夠解釋為什麼無法滿足請求，實體應該解釋拒絕的原因。 當然，如果伺服器不想讓客戶端取得訊息，也可以回傳404回應。 |
| 404 | 請求失敗，在伺服器上找不到請求的資源。 沒有資訊告訴使用者這種情況是暫時的還是永久的。 如果伺服器知道這種情況，它應該使用 410 狀態代碼告訴舊資源由於其內部配置機制出現問題而永久不可用並且它沒有地址可以跳轉到。 當伺服器不想透露請求被拒絕的原因或沒有其他適當的回應時，廣泛使用 404 狀態代碼。 |
| 405 | 無法使用請求行中指定的請求方法請求對應的資源。 回應應傳回一個 Allow 標頭以指示目前資源可以接受的請求方法清單。 考慮到 PUT，DELETE 方法將資源寫入伺服器，因此大多數 Web 伺服器在其預設配置中不支援或不允許上述請求方法，並為此類請求傳回 405 錯誤。 |
| 406 | 請求資源的內容特徵不滿足請求頭中的條件，無法產生回應實體。 除非這是 HEAD 請求，否則回應應該傳回一個包含實體屬性和位址清單的實體，使用者或瀏覽器可以從中選擇最合適的一個。 實體的格式由 Content-Type 標頭中定義的媒體類型決定。 瀏覽器可以根據格式和獨特的功能做出最佳選擇。 然而，本規範並沒有定義進行這種自動選擇的標準。 |
| 407 | 類似於 401 回應，但客戶端必須透過代理伺服器進行身份驗證。 代理伺服器必須為身分查詢傳回 Proxy-Authenticate。 客戶端可以傳回 Proxy-Authorization 標頭進行驗證。 參見 RFC 2617. |
| 408 | 請求超時。 客戶端在伺服器準備等待的時間內沒有完成發送請求。 客戶端始終可以不加修改地重新發送此請求。 |
| 409 | 請求無法完成，因為它與所請求資源的當前狀態衝突。 僅當使用者可以解決衝突並重新提交新請求時才允許使用此代碼。 回應應包含足夠的訊息，以便使用者發現衝突的原因。 衝突通常發生在 PUT 請求的處理過程中。 例如，在版本檢查環境中，如果PUT發送的特定資源修改請求所附帶的版本資訊與先前的（第三方）請求衝突，此時伺服器應該會傳回409錯誤。 通知用戶請求無法完成。 此時，回應實體可能包含兩個衝突版本之間差異的比較，以便使用者可以在合併後重新提交新版本。 |
| 410 | 所請求的資源在伺服器上不再可用，並且沒有已知的轉發位址。 這種情況應該被認為是永久性的。 如果可能，具有連結編輯功能的用戶端應在獲得使用者許可後刪除對該位址的所有引用。 如果伺服器不知道或不確定這種情況是否是永久性的，它應該使用 404 狀態代碼。 除非另有說明，否則此回應是可快取的。 410 回應的主要目的是讓站長維護網站，通知用戶該資源不再可用，以及讓伺服器擁有者刪除對該資源的所有遠端連線。 僅此而已。 像這樣的事件在限時增值業務中屢見不鮮。 類似地，410 回應也用於通知目前伺服器站點的用戶端，原屬於個人的資源不再可用。 當然，是不是所有永久不可用的資源都應該標記為"410"？ 此標簽應保留多長時間完全取決於伺服器擁有者。 |
| 411 | 伺服器拒絕接受未定義 Content-Length 標頭的請求。 在新增有效的 Content-Length 標頭指示請求訊息體的長度後，用戶端可以再次傳送請求。 |
| 412 | 在檢查請求標頭欄位中指定的先決條件時，伺服器無法滿足其中一項或多項。 此狀態碼允許客戶端在檢索資源時對請求的元資訊（請求頭字段資料）設定前置條件，以防止請求方法應用於所需內容以外的資源。 。 |
| 413 | 伺服器拒絕處理當前請求，因為請求發送的實體資料的大小超出了伺服器正在嘗試處理或可以處理的大小。 在這種情況下，伺服器可以關閉連線以防止客戶端繼續發送此請求。 如果這種情況是暫時的，伺服器應該會傳回一個 Retry-After 回應頭來告訴客戶端稍後可以重試幾次。 |
| 414 | 伺服器拒絕處理請求，因為請求 URI 長於伺服器可以解釋的長度。 這種情況比較少見，通常情況是： 應該使用 POST 方法的表單提交現在是 GET 方法和查詢字符串（Query 字符串）太長。 重定向 URI 中的"黑洞"。 例如，每次重定向都使用舊 URI 作為新 URI 的一部分，導致多次重定向後 URI 更長。 客戶端試圖攻擊在某些伺服器上有安全漏洞的伺服器。 這類型的伺服器使用固定長度的緩衝區來讀取和操作請求 URI。 如果 post-GET 參數超過某個值，可能會發生緩衝區溢位並可能執行任意程式碼 [1]。 沒有此類漏洞的伺服器應傳回 414 狀態代碼。 |
| 415 | 對於當前請求的方法和請求的資源，請求被拒絕，因為請求中發送的實體不是伺服器支援的格式。 |
| 416 | 如果請求中包含Range請求頭，Range中指定的數據範圍與當前資源的可用範圍不匹配，且請求中未定義If-Range請求頭，伺服器返回416狀態應該返回 代碼。 如果Range使用字節範圍，這種情況意味著請求指定的所有資料範圍的第一個字節位置超過了目前資源的長度。 伺服器也應傳回 416 狀態代碼，並包含一個 Content-Range 實體標頭，指示目前資源的長度。 此回應還不允許使用 multipart / byteranges 作為內容類型。 |
| 417 | 要麼Request header的Expect中指定的期望沒有被伺服器滿足，要麼有明確的證據表明伺服器是代理伺服器，當前路由中的下一個節點不滿足Expect的內容。 我有。 |
| 421 | 從目前客戶端的 IP 位址到伺服器的連線數已超過伺服器允許的最大範圍。 這裡的IP地址通常是指伺服器看到的客戶端位址（如用戶網關或代理伺服器的位址）。 在這種情況下，多個最終用戶可能會參與計算連線數。 |
| 422 | 從目前客戶端的 IP 位址到伺服器的連線數已超過伺服器允許的最大範圍。 這裡的IP地址通常是指伺服器看到的客戶端位址（如用戶網關或代理伺服器的位址）。 在這種情況下，多個最終用戶可能會參與計算連線數。 |
| 422 | 請求格式正確，但包含語義錯誤，無法回應。 (RFC 4918 WebDAV) 423 Locked 目前資源被鎖定。 (RFC 4918 WebDAV) |
| 424 | 目前請求因先前請求（如 PROPPATCH）中的錯誤而失敗。 (RFC 4918 WebDAV) |
| 425 | 在 WebDav 高階集合草案中定義，但未出現在 WebDAV 序列集協定 (RFC 3658) 中。 |
| 426 | 客戶端應切換到 TLS/1.0。 (RFC2817) |
| 449 | 由 Microsoft 增強，應在採取適當措施後重試代表請求。 |
| 500 | 伺服器遇到意外情況，無法完成您的請求。 一般伺服器程式碼不正確時會出現此問題。 |
| 501 | 伺服器不支援目前請求所需的功能。 如果伺服器無法識別請求的方法並且無法支援該資源請求。 |
| 502 | 充當網關或代理的伺服器在嘗試完成請求時收到來自上游伺服器的無效回應。 |
| 503 | 由於臨時伺服器維護或過載，伺服器目前無法處理請求。 這種狀態是暫時的，過一段時間就會恢復正常。 如果可以估計延遲，則回應可以包含指示延遲的 Retry-After 標頭。 如果未帕供此 Retry-After 訊息，用戶端應將其視為 500 回應。 注意：503 狀態代碼的存在並不意味著它應該在伺服器過載時使用。 有些伺服器只是想拒絕客戶端連線。 |
| 504 | 當充當網關或代理的伺服器試圖完成請求時，它無法從上游伺服器（由 URI 標識的伺服器，如 HTTP、FTP、LDAP 等）或輔助伺服器（DNS 等）接收回應。 ). 快速地。 注意：某些代理伺服器在 DNS 查詢逾時時傳回 400 或 500 錯誤。 |
| 505 | 伺服器不支援或拒絕支援請求中使用的 HTTP 版本。 這意味著伺服器不能或不想使用與客戶端相同的版本。 回應必須包含一個實體來解釋為什麼不支援該版本以及伺服器支援哪些協定。 |
| 506 | 由透明內容協商協議 (RFC 2295) 擴展以表示內部伺服器配置錯誤。 |
| 507 | 伺服器無法儲存完成請求所需的內容。 這種情況被認為是暫時的。 WebDAV（RFC 4918） |
| 509 | 伺服器已達到其帶寬限制。 這不是官方狀態代碼，但仍被廣泛使用。 |
| 510 | 取得資源所需的策略並不充分。 (RFC2774) |