http狀態碼定義

http狀態碼定義

每個狀態代碼如下所述,包括可以遵循哪些方法以及響應中需要的任何元信息的描述。

信息1xx

此類狀態碼錶示臨時響應,僅由狀態行和可選標頭組成,並由空行終止。此類狀態代碼沒有必需的標題。由於HTTP / 1.0沒有定義任何1xx狀態代碼,因此除實驗條件外,服務器不得向HTTP / 1.0客戶端發送1xx響應。

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

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

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

100 繼續

客戶應該繼續請求。該臨時響應用於通知客戶端請求的初始部分已被接收,並且尚未被服務器拒絕。客戶端應繼續發送請求的剩餘部分,或者如果請求已經完成,則忽略該響應。服務器必須在請求完成後發送最終響應。有關使用和處理此狀態代碼的詳細討論,

101切換協議

服務器通過升級消息頭字段 瞭解並願意遵守客戶端的請求,以便更改此連接上使用的應用協議。服務器將在終止101響應的空行之後立即將協議切換到由響應的“升級”頭字段定義的協議。

只有在有利的情況下才應該切換協議。例如,切換到較新版本的HTTP對於舊版本是有利的,並且當遞送使用這種特徵的資源時,切換到實時同步協議可能是有利的。

成功2xx

此類狀態碼錶示客戶端的請求已成功接收,理解並被接受。

200 OK

請求成功。與響應一起返回的信息取決於請求中使用的方法,例如:

GET響應中發送對應於所請求資源的實體;

HEAD與所請求的資源相對應的實體頭部字段在沒有任何消息體的響應中發送;

POST一個描述或包含動作結果的實體;

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

201 OK

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

201響應可以包含ETag響應頭字段,指示剛創建的請求變體的實體標籤的當前值,

202 已接受

該請求已被接受處理,但處理尚未完成。該請求可能或可能不會最終被執行,因爲在處理實際發生時可能不允許。沒有可以從異步操作(如此)重新發送狀態代碼的功能。

202迴應是故意不提交的。其目的是允許服務器接受一些其他進程的請求(可能是每天僅運行一次的面向批次的進程),而不要求用戶代理與服務器的連接持續到進程完成爲止。該響應返回的實體應該包括請求的當前狀態的指示,以及指向狀態監視器的指針,或者用戶何時可以期望該請求被滿足的估計。

203 非授權信息

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

204 無內容

服務器已經滿足了請求,但不需要返回一個實體,並且可能希望返回更新的元信息。響應可以包括實體標題形式的新的或更新的元信息,如果存在,則應該與所請求的變體相關聯。

如果客戶端是用戶代理,則不應將其文檔視圖與導致請求發送的文檔視圖進行更改。該響應主要是爲了允許進行動作的輸入,而不會導致更改用戶代理的活動文檔視圖,儘管任何新的或更新的元信息應該應用於當前在用戶代理的活動視圖中的文檔。

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

205 重置內容

服務器已滿足請求,用戶代理應該重置導致發送請求的文檔視圖。該響應主要旨在允許通過用戶輸入進行動作的輸入,隨後清除輸入的形式,使得用戶可以容易地啓動另一個輸入動作。答覆不能包括實體。

206 部分內容

服務器已經滿足資源的部分GET請求。請求必須包括一個指示期望範圍的範圍標題字段,並且可以包括一個If-Range頭字段來使請求成爲條件。

響應必須包括以下標題字段:

      - 內容範圍標題字段
        該響應包含的範圍,或多部分/ byteranges
        Content-Type包含每個部分的Content-Range字段。如果一個
        Content-Length頭字段存在於響應中
        值必須匹配傳輸的OCTET的實際數量
        消息體。
      - 日期
      -  ETag和/或Content-Location,如果標題將被髮送
        在200響應相同的請求
      - 如果字段值可能,則到期,Cache-Control和/或Vary
        不同於以前在任何響應中發送的
        變種

如果206響應是使用強緩存驗證器的If-Range請求的結果,響應應不包括其他實體頭。如果響應是使用弱驗證器的If-Range請求的結果,則響應不能包括其他實體頭; 這可以防止緩存的實體和更新的標頭之間的不一致。否則,響應必須包括所有返回的實體標題,並返回200(OK)響應到相同的請求。

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

不支持Range和Content-Range標頭的緩存不能緩存206(Partial)響應。

重定向3xx

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

      注意:此規範的以前版本推薦a
      最多五個重定向。內容開發者應該知道
      可能有客戶端實施這樣一個固定的
      侷限性。

300 多項選擇

所請求的資源對應於一組表示中的任何一個,每個具有其自己的特定位置,並且正在提供代理驅動的協商信息,使得用戶(或用戶代理)可以選擇優選的表示並將其重定向請求到該位置。

除非是HEAD請求,響應應該包括一個包含資源特徵列表和位置的實體,用戶或用戶代理可從中選擇最合適的一個。實體格式由Content-Type頭域中指定的媒體類型指定。取決於格式和功能

用戶代理,選擇最合適的選擇可以自動執行。然而,本規範並沒有定義這種自動選擇的任何標準。

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

301 永久移動

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

新的永久URI應該由響應中的位置字段給出。除非請求方法是HEAD,響應的實體應該包含一個帶有超鏈接到新URI的超文本短信。

如果爲了響應除GET或HEAD之外的請求而接收到301狀態碼,用戶代理不得自動重定向請求,除非用戶可以確認,否則可能會更改發出請求的條件。

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

302 臨時移動

請求的資源暫時駐留在不同的URI下。由於重定向有時可能會被更改,所以客戶端應該繼續使用Request-URI來應對未來的請求。如果由Cache-Control或Expires標頭字段指示,此響應只能緩存。

臨時URI應該由響應中的位置字段給出。除非請求方法是HEAD,響應的實體應該包含一個帶有超鏈接到新URI的超文本短信。

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

      注意:RFC 1945和RFC 2068指定不允許客戶端
      更改重定向請求的方法。但是,大多數
      現有的用戶代理實現將302看作是303
      響應,在位置字段值上執行GET
      的原始請求方法。狀態碼303和307有
      被添加到希望明確清楚哪個服務器
      客戶預計會有一些反應。

303 查看其它地址

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

響應中的位置字段應該給出不同的URI。除非請求方法是HEAD,響應的實體應該包含一個帶有超鏈接到新URI的超文本短信。

      注意:許多HTTP / 1.1之前的用戶代理不明白303
      狀態。當與這樣的客戶端的互操作性是一個問題時,
      可以使用302狀態代碼,因爲大多數用戶代理作出反應
      到302所述的響應,如303所述。

304 未修改

如果客戶端執行了條件GET請求,並且允許訪問,但是該文檔尚未被修改,則服務器應該使用該狀態代碼進行響應。304響應不能包含消息體,因此總是在頭字段之後的第一個空行終止。

響應必須包括以下標題字段:

      - 日期,

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

      -  ETag和/或Content-Location,如果標題將被髮送
        在200響應相同的請求
      - 如果字段值可能,則到期,Cache-Control和/或Vary
        不同於以前在任何響應中發送的
        變種

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

如果304響應指示當前未緩存的實體,則高速緩存必須忽略該響應並重復該請求而不具有條件。

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

305 使用代理

所請求的資源必須通過位置字段給出的代理進行訪問。位置字段給出代理的URI。收件人預計將通過代理重複此單一請求。305響應必須僅由源服務器生成。

      注意:RFC 2068並不清楚305是爲了重定向一個
      單一請求,僅由原始服務器生成。不
      觀察這些限制具有重大的安全後果。

306(未使用)

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

307 臨時重定向

請求的資源暫時駐留在不同的URI下。由於重定向可能有時被改變,所以客戶端應該繼續使用Request-URI來應對未來的請求。如果由Cache-Control或Expires標頭字段指示,此響應只能緩存。

臨時URI應該由響應中的位置字段給出。除非請求方法是HEAD,否則響應的實體應該包含一個具有超鏈接到新URI的短超文本註釋,因爲許多HTTP / 1.1之前的用戶代理不瞭解307狀態。因此,該筆記應包含用戶在新URI上重複原始請求所需的信息。

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

客戶端錯誤4xx

4xx類的狀態代碼適用於客戶端似乎有錯誤的情況。除了響應HEAD請求之外,服務器應該包含一個包含錯誤情況說明的實體,以及它是一個臨時的還是永久的。這些狀態碼適用於任何請求方式。用戶代理應該向用戶顯示任何包含的實體。

如果客戶端正在發送數據,則在服務器關閉輸入連接之前,使用TCP的服務器實現應該小心,以確保客戶端確認收到包含響應的數據包。如果客戶端在關閉後繼續向服務器發送數據,則服務器的TCP堆棧將向客戶端發送一個重置數據包,這可能會擦除客戶端未確認的輸入緩衝區,然後才能被HTTP應用程序讀取和解釋。

400 錯誤請求

由於格式錯誤,服務器無法理解該請求。客戶端不要重複請求而不進行修改。

401 未經授權

該請求需要用戶認證。響應必須包括一個WWW-Authenticate頭字段,其中包含適用於所請求資源的挑戰。客戶端可以使用合適的授權頭域重複該請求。如果請求已經包含授權憑據,那麼401響應表明這些憑據已被拒絕授權。如果401響應包含與先前響應相同的挑戰,並且用戶代理已經嘗試至少進行一次認證,則應該向用戶呈現在響應中給出的實體,因爲該實體可能包括相關的診斷信息。HTTP訪問認證在“HTTP認證:

402

此代碼保留供將來使用。

403 拒絕

服務器瞭解該請求,但拒絕履行該請求。授權不會有幫助,請求不能重複。如果請求方法不是HEAD,並且服務器希望公開爲什麼請求尚未實現,則應該描述拒絕實體的原因。如果服務器不希望將此信息提供給客戶端,則可以使用狀態代碼404(未找到)。

404 未找到

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

405 不允許的方法

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

406 不可接受

由請求標識的資源僅能夠根據請求中發送的接受頭來生成內容特徵不可接受的響應實體。

除非是HEAD請求,響應應該包括一個包含可用實體特徵和位置列表的實體,用戶或用戶代理可從中選擇最合適的一個。實體格式由Content-Type頭字段中指定的媒體類型指定。根據用戶代理的格式和功能,可以自動執行最合適的選擇。然而,本規範並沒有定義這種自動選擇的任何標準。

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

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

407 需要代理驗證

此代碼類似於401(未經授權),但表示客戶端必須首先使用代理身份驗證自身。代理務必返回一個代理驗證頭域,其中包含適用於所請求資源的代理的挑戰。客戶端可以使用合適的代理授權頭域重複該請求)。HTTP訪問認證在“HTTP認證:基本和摘要訪問認證”

408 請求超時

客戶端在服務器準備等待的時間內沒有產生請求。客戶可以隨時重複請求而不進行修改。

409 衝突

由於與資源的當前狀態衝突,無法完成該請求。只有在預期用戶可能能夠解決衝突並重新提交請求的情況下,才允許使用此代碼。響應機構應該包括足夠的

信息供用戶識別衝突的根源。理想情況下,響應實體將包括足夠的信息供用戶或用戶代理解決問題; 然而,這可能是不可能的,不是必需的。

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

410 所請求的資源在服務器上不再可用

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

410響應主要旨在通過向收件人通知資源有意不可用並且服務器所有者希望刪除該資源的遠程鏈接來幫助Web維護任務。這種事件對於有限時間,促銷服務以及屬於不再在服務器站點工作的個人的資源是常見的。沒有必要將所有永久不可用的資源標記爲“已經”或將標記保持在任何時間長度 – 這由服務器所有者決定。

411 需要Content-Length

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

412 客戶端請求信息的先決條件錯誤

在服務器上測試的一個或多個請求頭字段中給出的前提條件被評估爲false。該響應代碼允許客戶端在當前資源元信息(頭字段數據)上放置前提條件,從而防止所請求的方法被應用於除預期的資源之外的資源。

413 請求實體太大

服務器拒絕處理請求,因爲請求實體大於服務器願意或能夠處理的請求實體。服務器可能會關閉連接,以防止客戶端繼續請求。

如果條件是臨時的,則服務器應該包括一個Retry-After頭域,以指示它是臨時的,並且在什麼時候客戶端可以再次嘗試。

414 請求URI太長

服務器拒絕服務請求,因爲Request-URI比服務器願意解釋更長。當客戶端已經下降到重定向的URI“黑洞”(例如,指向重定向的URI前綴)時,當客戶端將POST請求正確轉換爲具有長查詢信息的GET請求時,這種罕見的條件纔可能發生本身的後綴),或者服務器受到試圖利用固定長度緩衝區中存在的某些服務器中存在的安全漏洞的客戶端進行***,以讀取或操作Request-URI。

415 不支持的介質類型

服務器拒絕服務請求,因爲請求的實體是被請求的方法所請求資源不支持的格式。

416 請求範圍無效

如果請求包含Range請求頭字段,服務器應該返回一個具有該狀態碼的響應,並且此字段中的範圍說明符值中的任何一個都不與所選資源的當前範圍重疊,並且請求沒有包括一個If-Range請求頭字段。(對於字節範圍,這意味着所有字節範圍規範值的第一個字節位數大於所選資源的當前長度。)

當返回一個字節範圍請求的狀態碼時,響應應該包括一個Content-Range entity-header字段,指定所選資源的當前長度。此響應不得使用multipart / byteranges內容類型。

417 服務器無法滿足Expect的請求頭信息

該服務器無法滿足Expect請求頭字段中給出的信息,或者如果服務器是代理服務器,則服務器具有明確的證據表明下一跳服務器無法滿足該請求。

 服務器錯誤5xx

以數字“5”開頭的響應狀態代碼表示服務器知道它已經發生錯誤或不能執行請求的情況。除了響應HEAD請求之外,服務器應該包含一個包含錯誤情況說明的實體,以及它是一個臨時的還是永久的。用戶代理應該向用戶顯示任何包含的實體。這些響應代碼適用於任何請求方法。

500內部服務器錯誤

服務器遇到意外的情況,阻止它滿足請求。

501 未實施

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

502 壞網關

作爲網關或代理的服務器在嘗試完成請求時從其訪問的上游服務器接收到無效響應。

503 服務不可用

由於服務器的臨時重載或維護,服務器目前無法處理請求。這意味着這是一個暫時的條件,這將在一段延遲之後得到緩解。如果知道,延遲的長度可以在Retry-After報頭中指示。如果沒有提供Retry-After,客戶端應該處理響應,就像500次響應一樣。

      注意:503狀態碼的存在並不意味着a
      服務器在重載時必須使用它。有些服務器可能希望
      簡單地拒絕連接。

504 網關超時

作爲網關或代理服務器的服務器沒有從嘗試完成訪問所需的URI(例如HTTP,FTP,LDAP)或其他輔助服務器(例如DNS)指定的上游服務器收到及時的響應請求。

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

505 不支持HTTP版本

服務器不支持或拒絕支持請求消息中使用的HTTP協議版本。服務器表示它不能或不願意使用與客戶端相同的主要版本來完成請求,而不是此錯誤消息。響應應該包含一個描述爲什麼不支持該版本以及該服務器支持哪些其他協議的實體。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章