下面描述了每個狀態碼,包括它可以遵循的方法的描述以及響應中所需的任何元信息。

10.1信息 1xx

此類狀態代碼表示臨時響應,僅由 Status-Line 和可選標題組成,并以空行終止。此類狀態代碼沒有必需的標頭。由于 HTTP/1.0 沒有定義任何 1xx 狀態代碼,服務器不得向 HTTP/1.0 客戶端發送 1xx 響應,除非在實驗條件下。

客戶端必須準備好在常規響應之前接受一個或多個 1xx 狀態響應,即使客戶端不期望 100(繼續)狀態消息。用戶代理可能會忽略意外的 1xx 狀態響應。

代理必須轉發 1xx 響應,除非代理與其客戶端之間的連接已關閉,或者除非代理本身請求生成 1xx 響應。(例如,如果一個

proxy 在轉發請求時添加了“Expect: 100-continue”字段,則不需要轉發相應的 100(繼續)響應。)

10.1.1 100 繼續

客戶端應該繼續它的請求。此臨時響應用于通知客戶端已收到請求的初始部分并且尚未被服務器拒絕。客戶端應該繼續發送請求的剩余部分,或者,如果請求已經完成,則忽略此響應。服務器必須在請求完成后發送最終響應。

10.1.2 101 交換協議

服務器通過升級消息頭字段(第 14.42 節)理解并愿意遵守客戶端的請求,以更改在此連接上使用的應用程序協議。服務器將在終止 101 響應的空行之后立即將協議切換到響應的 Upgrade 標頭字段定義的協議。

只有在有利的情況下才應切換協議。例如,切換到較新版本的 HTTP 比舊版本更有優勢,而在交付使用此類功能的資源時,切換到實時、同步協議可能更有優勢。

10.2成功2xx

此類狀態碼表示客戶端的請求被成功接收、理解和接受。

10.2.1 200 正常

請求已成功。響應返回的信息取決于請求中使用的方法,例如:

GET 在響應中發送與請求的資源對應的實體;

HEAD 請求資源對應的實體頭字段在響應中發送,不帶任何消息體;

POST 描述或包含操作結果的實體;

TRACE 包含終端服務器收到的請求消息的實體。

10.2.2 201 創建

請求已完成并導致創建新資源。新創建的資源可以被響應實體中返回的 URI 引用,資源的最具體的 URI 由 Location 頭字段給出。響應應該包含一個實體,其中包含資源特征和位置列表,用戶或用戶代理可以從中選擇最合適的一個。實體格式由 Content-Type 標頭字段中給出的媒體類型指定。源服務器必須在返回 201 狀態碼之前創建資源。如果無法立即執行該操作,則服務器應該使用 202(已接受)響應來響應。

一個 201 響應可能包含一個 ETag 響應頭字段,指示剛剛創建的請求變體的實體標簽的當前值。

10.2.3 202 接受

請求已被接受處理,但處理尚未完成。該請求最終可能會或可能不會被執行,因為在實際進行處理時它可能會被禁止。無法從諸如此類的異步操作中重新發送狀態代碼。

202 響應是故意不置可否的。它的目的是允許服務器接受對其他進程的請求(可能是一個每天只運行一次的面向批處理的進程),而不需要用戶代理與服務器的連接持續到進程完成。與此響應一起返回的實體應該包括請求當前狀態的指示以及指向狀態監視器的指針或用戶可以期望何時完成請求的一些估計。

10.2.4 203 非權威信息

實體標頭中返回的元信息不是原始服務器可用的最終集,而是從本地或第三方副本收集的。呈現的集合可能是原始版本的子集或超集。例如,包含有關資源的本地注釋信息可能會導致源服務器已知的元信息的超集。不需要使用此響應代碼,僅當響應為 200(OK)時才適用。

10.2.5 204 無內容

服務器已完成請求,但不需要返回實體主體,并且可能希望返回更新的元信息。響應可能包括實體頭形式的新的或更新的元信息,如果存在,應該與請求的變體相關聯。

如果客戶端是用戶代理,它不應該改變導致請求被發送的文檔視圖。這個響應主要是為了允許輸入動作發生而不導致用戶代理的活動文檔視圖發生變化,盡管任何新的或更新的元信息應該應用于當前在用戶代理的活動視圖中的文檔。

204 響應不能包含消息體,因此總是由頭字段之后的第一個空行終止。

10.2.6 205 重置內容

服務器已經完成了請求并且用戶代理應該重置導致請求被發送的文檔視圖。此響應主要是為了允許通過用戶輸入進行操作的輸入,然后清除給出輸入的表單,以便用戶可以輕松地啟動另一個輸入操作。響應不得包含實體。

10.2.7 206 部分內容

服務器已完成對資源的部分 GET 請求。請求必須包含一個 Range 標頭字段(第 14.35 節)指示所需的范圍,并且可以包含一個 If-Range 標頭字段以使請求有條件。

響應必須包含以下標頭字段:

      - Content-Range 標頭字段(第 14.16 節)指示
        此響應中包含的范圍,或 multipart/byteranges
        Content-Type 包括每個部分的 Content-Range 字段。如果一個
        Content-Length 頭域存在于響應中,它的
        值必須與實際發送的 OCTET 數量相匹配
        郵件正文。

      - 日期

      - ETag 和/或 Content-Location,如果標頭已發送
        在對同一請求的 200 響應中

      - 過期、緩存控制和/或變化,如果字段值可能
        與之前任何相同的響應中發送的不同
        變體

如果 206 響應是使用強緩存驗證器的 If-Range 請求的結果(請參閱第 13.3.3 節),則響應不應包含其他實體標頭。如果響應是使用弱驗證器的 If-Range 請求的結果,則響應不得包含其他實體標頭;這可以防止緩存的實體主體和更新的標頭之間的不一致。否則,響應必須包含對同一請求的 200(OK)響應返回的所有實體標頭。

如果 ETag 或 Last-Modified 標頭不完全匹配,則緩存不得將 206 響應與其他先前緩存的內容組合。

不支持 Range 和 Content-Range 標頭的緩存不得緩存 206(部分)響應。

10.3重定向 3xx

此類狀態碼表明用戶代理需要采取進一步的行動才能滿足請求。當且僅當第二個請求中使用的方法是 GET 或 HEAD 時,用戶代理可以執行所需的操作,而無需與用戶交互。客戶端應該檢測無限重定向循環,因為這樣的循環會為每個重定向生成網絡流量。

      注意:本規范的先前版本建議使用
      最多五個重定向。內容開發者應該意識到
      可能有客戶端實現了這樣一個固定的
      局限性。

10.3.1 300 多項選擇

請求的資源對應于一組表示中的任何一個,每個表示都有自己的特定位置,并且正在提供代理驅動的協商信息(第 12 節),以便用戶(或用戶代理)可以選擇首選表示并重定向其請求該位置。

除非它是一個 HEAD 請求,否則響應應該包含一個實體,該實體包含一個資源特征和位置列表,用戶或用戶代理可以從中選擇最合適的一個。實體格式由 ContentType 標頭字段中給出的媒體類型指定。取決于格式和能力

用戶代理,最合適的選擇可能會自動執行。但是,本規范沒有為這種自動選擇定義任何標準。

如果服務器有首選的表示形式,它應該在 Location 字段中包含該表示形式的特定 URI;用戶代理可以使用 Location 字段值進行自動重定向。除非另有說明,否則此響應是可緩存的。

10.3.2 301 永久移動

請求的資源已被分配一個新的永久 URI,并且任何將來對該資源的引用都應該使用返回的 URI 之一。如果可能,具有鏈接編輯功能的客戶端應該自動將對 Request-URI 的引用重新鏈接到服務器返回的一個或多個新引用。除非另有說明,否則此響應是可緩存的。

新的永久 URI 應該由響應中的 Location 字段給出。除非請求方法是 HEAD,否則響應的實體應該包含一個簡短的超文本注釋,其中包含指向新 URI 的超鏈接。

如果收到 301 狀態代碼以響應 GET 或 HEAD 以外的請求,用戶代理不得自動重定向請求,除非用戶可以確認,因為這可能會改變發出請求的條件。

      注意:當自動重定向 POST 請求后
      接收 301 狀態碼,一些現有的 HTTP/1.0 用戶代理
      會錯誤地將其更改為 GET 請求。

10.3.3 302 找到

請求的資源臨時駐留在不同的 URI 下。由于重定向有時可能會改變,客戶端應該繼續使用 Request-URI 來處理未來的請求。此響應僅在由 Cache-Control 或 Expires 標頭字段指示時才可緩存。

臨時 URI 應該由響應中的 Location 字段給出。除非請求方法是 HEAD,否則響應的實體應該包含一個簡短的超文本注釋,其中包含指向新 URI 的超鏈接。

如果收到 302 狀態碼以響應 GET 或 HEAD 以外的請求,除非用戶可以確認,否則用戶代理不得自動重定向請求,因為這可能會改變發出請求的條件。

      注意:RFC 1945 和 RFC 2068 指定不允許客戶端
      更改重定向請求的方法。然而,大多數
      現有的用戶代理實現將 302 視為 303
      響應,對 Location 字段值執行 GET
      的原始請求方法。狀態碼 303 和 307 有
      為希望明確明確哪個服務器添加了
      期望客戶的反應。

10.3.4 303 見其他

可以在不同的 URI 下找到對請求的響應,并且應該使用該資源上的 GET 方法來檢索。此方法的存在主要是為了允許 POST 激活腳本的輸出將用戶代理重定向到選定的資源。新的 URI 不是原始請求資源的替代引用。303 響應不能被緩存,但對第二個(重定向)請求的響應可能是可緩存的。

不同的 URI 應該由響應中的 Location 字段給出。除非請求方法是 HEAD,否則響應的實體應該包含一個簡短的超文本注釋,其中包含指向新 URI 的超鏈接。

      注意:許多 HTTP/1.1 之前的用戶代理不理解 303
      地位。當與此類客戶端的互操作性是一個問題時,
      可以使用 302 狀態碼代替,因為大多數用戶代理會做出反應
      對 302 響應,如此處針對 303 所述。

10.3.5 304 未修改

如果客戶端已經執行了一個條件 GET 請求并且允許訪問,但是文檔沒有被修改,服務器應該用這個狀態碼來響應。304 響應不能包含消息體,因此總是由頭字段之后的第一個空行終止。

響應必須包含以下標頭字段:

      - 日期,除非第 14.18.1 節要求省略

如果無時鐘源服務器遵守這些規則,并且代理和客戶端將自己的 Date 添加到沒有收到的任何響應中(如 [RFC 2068]),則緩存將正確運行。

      - ETag 和/或 Content-Location,如果標頭已發送
        在對同一請求的 200 響應中

      - 過期、緩存控制和/或變化,如果字段值可能
        與之前任何相同的響應中發送的不同
        變體

如果條件 GET 使用了強緩存驗證器(參見第 13.3.3 節),則響應不應包含其他實體標頭。否則(即,條件 GET 使用弱驗證器),響應不得包含其他實體標頭;這可以防止緩存的實體主體和更新的標頭之間的不一致。

如果 304 響應指示當前未緩存的實體,則緩存必須忽略響應并在沒有條件的情況下重復請求。

如果緩存使用接收到的 304 響應來更新緩存條目,則緩存必須更新該條目以反映響應中給出的任何新字段值。

10.3.6 305 使用代理

請求的資源必須通過 Location 字段給出的代理訪問。Location 字段給出了代理的 URI。接收者應該通過代理重復這個單一的請求。305 響應必須只能由源服務器生成。

      注意:RFC 2068 并不清楚 305 旨在重定向
      單個請求,并且僅由源服務器生成。不是
      遵守這些限制會產生重大的安全后果。

10.3.7 306(未使用)

306 狀態碼在以前的規范版本中使用,不再使用,代碼被保留。

10.3.8 307 臨時重定向

請求的資源臨時駐留在不同的 URI 下。由于重定向有時可能會改變,客戶端應該繼續使用 Request-URI 來處理未來的請求。此響應僅在由 Cache-Control 或 Expires 標頭字段指示時才可緩存。

臨時 URI 應該由響應中的 Location 字段給出。除非請求方法是 HEAD,否則響應的實體應該包含一個簡短的超文本注釋,其中包含指向新 URI 的超鏈接,因為許多 HTTP/1.1 之前的用戶代理不理解 307 狀態。因此,注釋應該包含用戶在新 URI 上重復原始請求所需的信息。

如果收到 307 狀態代碼以響應 GET 或 HEAD 以外的請求,除非用戶可以確認,否則用戶代理不得自動重定向請求,因為這可能會改變發出請求的條件。

10.4客戶端錯誤 4xx

4xx 類狀態碼適用于客戶端似乎出錯的情況。除了響應 HEAD 請求時,服務器應該包含一個實體,其中包含對錯誤情況的解釋,以及它是暫時的還是永久的情況。這些狀態碼適用于任何請求方法。用戶代理應該向用戶顯示任何包含的實體。

如果客戶端正在發送數據,使用 TCP 的服務器實現應該小心確?？蛻舳嗽诜掌麝P閉輸入連接之前確認收到包含響應的數據包。如果客戶端在關閉后繼續向服務器發送數據,則服務器的 TCP 堆棧將向客戶端發送一個重置數據包,這可能會在 HTTP 應用程序讀取和解釋客戶端未確認的輸入緩沖區之前擦除它們。

10.4.1 400 錯誤請求

由于語法錯誤,服務器無法理解該請求。客戶端不應該在沒有修改的情況下重復請求。

10.4.2 401 未經授權

該請求需要用戶身份驗證。響應必須包含一個 WWW-Authenticate 頭字段(第 14.47 節),其中包含適用于所請求資源的質詢。客戶端可以使用合適的 Authorization 頭域重復請求。如果請求已包含授權憑證,則 401 響應指示已拒絕對這些憑證的授權。如果 401 響應包含與先前響應相同的質詢,并且用戶代理已經嘗試了至少一次身份驗證,則應該向用戶呈現響應中給出的實體,因為該實體可能包含相關的診斷信息。HTTP 訪問身份驗證在“HTTP 身份驗證:基本和摘要訪問身份驗證"中進行了說明。

10.4.3 402 需要付款

此代碼保留供將來使用。

10.4.4 403 禁止

服務器理解請求,但拒絕執行。授權將無濟于事,并且不應重復請求。如果請求方法不是 HEAD 并且服務器希望公開請求未完成的原因,它應該在實體中描述拒絕的原因。如果服務器不希望向客戶端提供此信息,則可以使用狀態代碼 404(未找到)來代替。

10.4.5 404 未找到

服務器未找到任何與請求 URI 匹配的內容。沒有說明這種情況是暫時的還是永久性的。如果服務器通過一些內部可配置的機制知道舊資源永久不可用并且沒有轉發地址,則應該使用 410 (Gone) 狀態代碼。當服務器不希望確切地揭示請求被拒絕的原因或沒有其他響應適用時,通常使用此狀態代碼。

10.4.6 405 方法不允許

Request-URI 所標識的資源不允許使用 Request-Line 中指定的方法。響應必須包含一個 Allow 標頭,其中包含所請求資源的有效方法列表。

10.4.7 406 不可接受

請求標識的資源只能根據請求中發送的接受頭生成具有不可接受的內容特征的響應實體。

除非它是一個 HEAD 請求,否則響應應該包括一個實體,該實體包含一個可用實體特征和位置的列表,用戶或用戶代理可以從中選擇最合適的一個。實體格式由 Content-Type 標頭字段中給出的媒體類型指定。根據用戶代理的格式和能力,可以自動選擇最合適的選項。但是,本規范沒有為這種自動選擇定義任何標準。

      注意:HTTP/1.1 服務器可以返回響應,這些響應是
      根據發送的接受標頭不可接受
      要求。在某些情況下,這甚至可能比發送
      406 響應。鼓勵用戶代理檢查
      傳入響應以確定它是否可以接受。

如果響應可能不可接受,用戶代理應該暫時停止接收更多數據并詢問用戶以決定進一步的操作。

10.4.8 407 需要代理驗證

此代碼類似于 401(未授權),但表示客戶端必須首先通過代理驗證自己。代理必須返回一個 Proxy-Authenticate 頭字段,其中包含適用于所請求資源的代理的質詢。客戶端可以使用合適的 Proxy-Authorization 頭域重復請求。HTTP 訪問身份驗證在“HTTP 身份驗證:基本和摘要訪問身份驗證” 中進行了說明。

10.4.9 408 請求超時

在服務器準備等待的時間內,客戶端沒有產生請求。客戶端可以在以后的任何時間重復請求而無需修改。

10.4.10 409 沖突

由于與資源的當前狀態沖突,無法完成請求。僅在預期用戶可能能夠解決沖突并重新提交請求的情況下才允許使用此代碼。響應正文應該包含足夠的

供用戶識別沖突來源的信息。理想情況下,響應實體將包含足夠的信息供用戶或用戶代理解決問題;但是,這可能是不可能的,也不是必需的。

響應 PUT 請求時最有可能發生沖突。例如,如果正在使用版本控制并且被 PUT 的實體包含對資源的更改,這些更改與早期(第三方)請求所做的更改相沖突,則服務器可能會使用 409 響應來指示它無法完成請求. 在這種情況下,響應實體可能會以響應 Content-Type 定義的格式包含兩個版本之間差異的列表。

10.4.11 410 走了

請求的資源在服務器上不再可用,并且不知道轉發地址。預計這種情況將被視為永久性的。具有鏈接編輯能力的客戶端應該在用戶批準后刪除對 Request-URI 的引用。如果服務器不知道或無法確定條件是否是永久的,則應該使用狀態代碼 404(未找到)。除非另有說明,否則此響應是可緩存的。

410 響應的主要目的是通過通知接收者該資源故意不可用并且服務器所有者希望刪除到該資源的遠程鏈接來協助 Web 維護任務。這種事件對于限時促銷服務和屬于不再在服務器站點工作的個人的資源很常見。沒有必要將所有永久不可用的資源標記為“已消失”或將標記保留任何時間 - 這由服務器所有者自行決定。

10.4.12 411 長度要求

服務器拒絕接受沒有定義 Content-Length 的請求。如果客戶端在請求消息中添加了包含消息體長度的有效 Content-Length 頭字段,則客戶端可以重復請求。

10.4.13 412 前置條件失敗

在服務器上測試時,一個或多個請求標頭字段中給出的前提條件評估為假。此響應代碼允許客戶端對當前資源元信息(標頭字段數據)設置先決條件,從而防止將請求的方法應用于預期之外的資源。

10.4.14 413 請求實體太大

服務器拒絕處理請求,因為請求實體大于服務器愿意或能夠處理的大小。服務器可以關閉連接以阻止客戶端繼續請求。

如果條件是臨時的,服務器應該包含一個 Retry-After 頭域來指示它是臨時的,并且在什么時間之后客戶端可以重試。

10.4.15 414 請求 URI 太長

服務器拒絕為請求提供服務,因為 Request-URI 比服務器愿意解釋的要長。這種罕見的情況只有在客戶端錯誤地將 POST 請求轉換為具有長查詢信息的 GET 請求時才可能發生,此時客戶端已下降到重定向的 URI“黑洞”(例如,重定向的 URI 前綴指向本身的后綴),或者當服務器受到客戶端的攻擊時,客戶端試圖利用某些服務器中存在的安全漏洞,使用固定長度的緩沖區來讀取或操作 Request-URI。

10.4.16 415 不支持的媒體類型

服務器拒絕為請求提供服務,因為請求的實體采用所請求方法的請求資源不支持的格式。

10.4.17 416 請求的范圍不滿足

如果請求包含 Range 請求標頭字段(第 14.35 節),并且此字段中的范圍說明符值沒有與所選資源的當前范圍重疊,并且請求沒有包括一個 If-Range 請求頭字段。(對于字節范圍,這意味著所有字節范圍規范值的第一個字節位置都大于所選資源的當前長度。)

當為字節范圍請求返回此狀態代碼時,響應應該包含一個 Content-Range 實體頭字段,指定所選資源的當前長度(參見第 14.16節)。此響應不得使用 multipart/byteranges 內容類型。

10.4.18 417 預期失敗

此服務器無法滿足在 Expect 請求頭字段(參見第 14.20 節)中給出的期望,或者,如果服務器是代理,則服務器有明確的證據表明下一跳服務器無法滿足該請求.

10.5服務器錯誤 5xx

以數字“5”開頭的響應狀態代碼表示服務器知道它已經出錯或無法執行請求的情況。除了響應 HEAD 請求時,服務器應該包含一個實體,其中包含對錯誤情況的解釋,以及它是暫時的還是永久的情況。用戶代理應該向用戶顯示任何包含的實體。這些響應代碼適用于任何請求方法。

10.5.1 500 內部服務器錯誤

服務器遇到了一個意外情況,導致它無法完成請求。

10.5.2 501 未實施

服務器不支持完成請求所需的功能。當服務器無法識別請求方法并且無法支持任何資源時,這是適當的響應。

10.5.3 502 錯誤網關

服務器在充當網關或代理時,在嘗試滿足請求時從它訪問的上游服務器接收到無效響應。

10.5.4 503 服務不可用

由于服務器臨時過載或維護,服務器當前無法處理請求。這意味著這是一種暫時的情況,經過一段時間的延遲會得到緩解。如果已知,延遲的長度可以在 Retry-After 標頭中指示。如果沒有給出 Retry-After,客戶端應該像處理 500 響應一樣處理響應。

      注意:503 狀態碼的存在并不意味著
      服務器在過載時必須使用它。一些服務器可能希望
      簡單地拒絕連接。

10.5.5 504 網關超時

服務器在充當網關或代理時,沒有收到來自 URI 指定的上游服務器(例如 HTTP、FTP、LDAP)或它在嘗試完成時需要訪問的其他輔助服務器(例如 DNS)的及時響應請求。

      注意:實現者注意:一些部署的代理是已知的
      當 DNS 查詢超時時返回 400 或 500。

10.5.6 505 HTTP 版本不支持

服務器不支持或拒絕支持請求消息中使用的 HTTP 協議版本。服務器表示它無法或不愿意使用與客戶端相同的主要版本完成請求,如第 3.1節所述,除了此錯誤消息。響應應該包含一個實體,描述為什么不支持該版本以及該服務器支持哪些其他協議。