HTTP狀態(tài)碼

HTTP狀態(tài)碼的分類

  • HTTP狀態(tài)碼由三個十進制數(shù)字組成乡革,第一個十進制數(shù)字定義了狀態(tài)碼的類型棒旗,后兩個數(shù)字沒有分類的作用。HTTP狀態(tài)碼共分為5種類型:
分類  分類描述
1** 信息,服務器收到請求削罩,需要請求者繼續(xù)執(zhí)行操作
2** 成功沦泌,操作被成功接收并處理
3** 重定向糊昙,需要進一步的操作以完成請求
4** 客戶端錯誤,請求包含語法錯誤或無法完成請求
5** 服務器錯誤谢谦,服務器在處理請求的過程中發(fā)生了錯誤

HTTP狀態(tài)碼表(版本1) 此表含狀態(tài)碼英文名稱

狀態(tài)碼 狀態(tài)碼英文名稱 中文描述
1開頭的狀態(tài)碼************************************
100 Continue    繼續(xù)释牺。客戶端應繼續(xù)其請求
101 Switching Protocols 切換協(xié)議回挽。服務器根據(jù)客戶端的請求切換協(xié)議没咙。只能切換到更 高級的協(xié)議,例如千劈,切換到HTTP的新版本協(xié)議
2開頭的狀態(tài)碼************************************
200 OK  請求成功祭刚。一般用于GET與POST請求
201 Created 已創(chuàng)建。成功請求并創(chuàng)建了新的資源
202 Accepted    已接受队塘。已經接受請求袁梗,但未處理完成
203 Non-Authoritative Information   非授權信息。請求成功憔古。但返回的meta信息不在原始的服務器遮怜,而是一個副本
204 No Content  無內容。服務器成功處理鸿市,但未返回內容锯梁。在未更新網頁的情況下,可確保瀏覽器繼續(xù)顯示當前文檔
205 Reset Content   重置內容焰情。服務器處理成功陌凳,用戶終端(例如:瀏覽器)應重置文檔視圖∧谥郏可通過此返回碼清除瀏覽器的表單域
206 Partial Content 部分內容合敦。服務器成功處理了部分GET請求
3開頭的狀態(tài)碼************************************
300 Multiple Choices    多種選擇。請求的資源可包括多個位置验游,相應可返回一個資源特征與地址的列表用于用戶終端(例如:瀏覽器)選擇
301 Moved Permanently   永久移動充岛。請求的資源已被永久的移動到新URI,返回信息會包括新的URI耕蝉,瀏覽器會自動定向到新URI崔梗。今后任何新的請求都應使用新的URI代替
302 Found   臨時移動。與301類似垒在。但資源只是臨時被移動蒜魄。客戶端應繼續(xù)使用原有URI
303 See Other   查看其它地址。與301類似谈为。使用GET和POST請求查看
304 Not Modified    未修改旅挤。所請求的資源未修改,服務器返回此狀態(tài)碼時峦阁,不會返回任何資源谦铃。客戶端通常會緩存訪問過的資源榔昔,通過提供一個頭信息指出客戶端希望只返回在指定日期之后修改的資源
305 Use Proxy   使用代理驹闰。所請求的資源必須通過代理訪問
306 Unused  已經被廢棄的HTTP狀態(tài)碼
307 Temporary Redirect  臨時重定向。與302類似撒会。使用GET請求重定向
4開頭的狀態(tài)碼************************************
400 Bad Request 客戶端請求的語法錯誤嘹朗,服務器無法理解
401 Unauthorized    請求要求用戶的身份認證
402 Payment Required    保留,將來使用
403 Forbidden   服務器理解請求客戶端的請求诵肛,但是拒絕執(zhí)行此請求
404 Not Found   服務器無法根據(jù)客戶端的請求找到資源(網頁)屹培。通過此代碼,網站設計人員可設置"您所請求的資源無法找到"的個性頁面
405 Method Not Allowed  客戶端請求中的方法被禁止
406 Not Acceptable  服務器無法根據(jù)客戶端請求的內容特性完成請求
407 Proxy Authentication Required   請求要求代理的身份認證怔檩,與401類似褪秀,但請求者應當使用代理進行授權
408 Request Time-out    服務器等待客戶端發(fā)送的請求時間過長,超時
409 Conflict    服務器完成客戶端的PUT請求是可能返回此代碼薛训,服務器處理請求時發(fā)生了沖突
410 Gone    客戶端請求的資源已經不存在媒吗。410不同于404,如果資源以前有現(xiàn)在被永久刪除了可使用410代碼乙埃,網站設計人員可通過301代碼指定資源的新位置
411 Length Required 服務器無法處理客戶端發(fā)送的不帶Content-Length的請求信息
412 Precondition Failed 客戶端請求信息的先決條件錯誤
413 Request Entity Too Large    由于請求的實體過大闸英,服務器無法處理,因此拒絕請求介袜。為防止客戶端的連續(xù)請求甫何,服務器可能會關閉連接。如果只是服務器暫時無法處理遇伞,則會包含一個Retry-After的響應信息
414 Request-URI Too Large   請求的URI過長(URI通常為網址)辙喂,服務器無法處理
415 Unsupported Media Type  服務器無法處理請求附帶的媒體格式
416 Requested range not satisfiable 客戶端請求的范圍無效
417 Expectation Failed  服務器無法滿足Expect的請求頭信息
5開頭的狀態(tài)碼************************************
500 Internal Server Error   服務器內部錯誤,無法完成請求
501 Not Implemented 服務器不支持請求的功能鸠珠,無法完成請求
502 Bad Gateway 充當網關或代理的服務器加派,從遠端服務器接收到了一個無效的請求
503 Service Unavailable 由于超載或系統(tǒng)維護,服務器暫時的無法處理客戶端的請求跳芳。延時的長度可包含在服務器的Retry-After頭信息中
504 Gateway Time-out    充當網關或代理的服務器,未及時從遠端服務器獲取請求
505 HTTP Version not supported  服務器不支持請求的HTTP協(xié)議的版本竹勉,無法完成處理

HTTP狀態(tài)碼列表(版本2) 此表的描述更詳細些

狀態(tài)碼 含義
100 客戶端應當繼續(xù)發(fā)送請求飞盆。這個臨時響應是用來通知客戶端它的部分請求已經被服務器接收,且仍未被拒絕∠判客戶端應當繼續(xù)發(fā)送請求的剩余部分孽水,或者如果請求已經完成,忽略這個響應城看。服務器必須在請求完成后向客戶端發(fā)送一個最終響應女气。
101 服務器已經理解了客戶端的請求,并將通過Upgrade 消息頭通知客戶端采用不同的協(xié)議來完成這個請求测柠。在發(fā)送完這個響應最后的空行后炼鞠,服務器將會切換到在Upgrade 消息頭中定義的那些協(xié)議。   只有在切換新的協(xié)議更有好處的時候才應該采取類似措施轰胁。例如谒主,切換到新的HTTP 版本比舊版本更有優(yōu)勢,或者切換到一個實時且同步的協(xié)議以傳送利用此類特性的資源赃阀。
102 由WebDAV(RFC 2518)擴展的狀態(tài)碼霎肯,代表處理將被繼續(xù)執(zhí)行。
200 請求已成功榛斯,請求所希望的響應頭或數(shù)據(jù)體將隨此響應返回观游。
201 請求已經被實現(xiàn),而且有一個新的資源已經依據(jù)請求的需要而建立驮俗,且其 URI 已經隨Location 頭信息返回懂缕。假如需要的資源無法及時建立的話,應當返回 '202 Accepted'意述。
202 服務器已接受請求提佣,但尚未處理。正如它可能被拒絕一樣荤崇,最終該請求可能會也可能不會被執(zhí)行拌屏。在異步操作的場合下,沒有比發(fā)送這個狀態(tài)碼更方便的做法了术荤。   返回202狀態(tài)碼的響應的目的是允許服務器接受其他過程的請求(例如某個每天只執(zhí)行一次的基于批處理的操作)倚喂,而不必讓客戶端一直保持與服務器的連接直到批處理操作全部完成。在接受請求處理并返回202狀態(tài)碼的響應應當在返回的實體中包含一些指示處理當前狀態(tài)的信息瓣戚,以及指向處理狀態(tài)監(jiān)視器或狀態(tài)預測的指針端圈,以便用戶能夠估計操作是否已經完成。
203 服務器已成功處理了請求子库,但返回的實體頭部元信息不是在原始服務器上有效的確定集合舱权,而是來自本地或者第三方的拷貝。當前的信息可能是原始版本的子集或者超集仑嗅。例如宴倍,包含資源的元數(shù)據(jù)可能導致原始服務器知道元信息的超級张症。使用此狀態(tài)碼不是必須的,而且只有在響應不使用此狀態(tài)碼便會返回200 OK的情況下才是合適的鸵贬。
204 服務器成功處理了請求俗他,但不需要返回任何實體內容,并且希望返回更新了的元信息阔逼。響應可能通過實體頭部的形式兆衅,返回新的或更新后的元信息。如果存在這些頭部信息嗜浮,則應當與所請求的變量相呼應羡亩。   如果客戶端是瀏覽器的話,那么用戶瀏覽器應保留發(fā)送了該請求的頁面周伦,而不產生任何文檔視圖上的變化夕春,即使按照規(guī)范新的或更新后的元信息應當被應用到用戶瀏覽器活動視圖中的文檔。   由于204響應被禁止包含任何消息體专挪,因此它始終以消息頭后的第一個空行結尾及志。
205 服務器成功處理了請求,且沒有返回任何內容寨腔。但是與204響應不同速侈,返回此狀態(tài)碼的響應要求請求者重置文檔視圖。該響應主要是被用于接受用戶輸入后迫卢,立即重置表單倚搬,以便用戶能夠輕松地開始另一次輸入。   與204響應一樣乾蛤,該響應也被禁止包含任何消息體每界,且以消息頭后的第一個空行結束。
206 服務器已經成功處理了部分 GET 請求家卖。類似于 FlashGet 或者迅雷這類的 HTTP 下載工具都是使用此類響應實現(xiàn)斷點續(xù)傳或者將一個大文檔分解為多個下載段同時下載氯庆。   該請求必須包含 Range 頭信息來指示客戶端希望得到的內容范圍弟孟,并且可能包含 If-Range 來作為請求條件很魂。   響應必須包含如下的頭部域:   Content-Range 用以指示本次響應中返回的內容的范圍毅待;如果是 Content-Type 為 multipart/byteranges 的多段下載,則每一 multipart 段中都應包含 Content-Range 域用以指示本段的內容范圍酪捡。假如響應中包含 Content-Length叁征,那么它的數(shù)值必須匹配它返回的內容范圍的真實字節(jié)數(shù)。   Date   ETag 和/或 Content-Location逛薇,假如同樣的請求本應該返回200響應捺疼。   Expires, Cache-Control,和/或 Vary永罚,假如其值可能與之前相同變量的其他響應對應的值不同的話啤呼。   假如本響應請求使用了 If-Range 強緩存驗證议薪,那么本次響應不應該包含其他實體頭;假如本響應的請求使用了 If-Range 弱緩存驗證媳友,那么本次響應禁止包含其他實體頭;這避免了緩存的實體內容和更新了的實體頭信息之間的不一致产捞。否則醇锚,本響應就應當包含所有本應該返回200響應中應當返回的所有實體頭部域。   假如 ETag 或 Last-Modified 頭部不能精確匹配的話坯临,則客戶端緩存應禁止將206響應返回的內容與之前任何緩存過的內容組合在一起焊唬。   任何不支持 Range 以及 Content-Range 頭的緩存都禁止緩存206響應返回的內容。
207 由WebDAV(RFC 2518)擴展的狀態(tài)碼看靠,代表之后的消息體將是一個XML消息赶促,并且可能依照之前子請求數(shù)量的不同,包含一系列獨立的響應代碼挟炬。
300 被請求的資源有一系列可供選擇的回饋信息鸥滨,每個都有自己特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器能夠自行選擇一個首選的地址進行重定向谤祖。   除非這是一個 HEAD 請求婿滓,否則該響應應當包括一個資源特性及地址的列表的實體,以便用戶或瀏覽器從中選擇最合適的重定向地址粥喜。這個實體的格式由 Content-Type 定義的格式所決定凸主。瀏覽器可能根據(jù)響應的格式以及瀏覽器自身能力,自動作出最合適的選擇额湘。當然卿吐,RFC 2616規(guī)范并沒有規(guī)定這樣的自動選擇該如何進行。   如果服務器本身已經有了首選的回饋選擇锋华,那么在 Location 中應當指明這個回饋的 URI嗡官;瀏覽器可能會將這個 Location 值作為自動重定向的地址。此外供置,除非額外指定谨湘,否則這個響應也是可緩存的。
301 被請求的資源已永久移動到新位置芥丧,并且將來任何對此資源的引用都應該使用本響應返回的若干個 URI 之一紧阔。如果可能,擁有鏈接編輯功能的客戶端應當自動把請求的地址修改為從服務器反饋回來的地址续担。除非額外指定擅耽,否則這個響應也是可緩存的。   新的永久性的 URI 應當在響應的 Location 域中返回物遇。除非這是一個 HEAD 請求乖仇,否則響應的實體中應當包含指向新的 URI 的超鏈接及簡短說明憾儒。   如果這不是一個 GET 或者 HEAD 請求,因此瀏覽器禁止自動進行重定向乃沙,除非得到用戶的確認起趾,因為請求的條件可能因此發(fā)生變化。   注意:對于某些使用 HTTP/1.0 協(xié)議的瀏覽器警儒,當它們發(fā)送的 POST 請求得到了一個301響應的話训裆,接下來的重定向請求將會變成 GET 方式。
302 請求的資源現(xiàn)在臨時從不同的 URI 響應請求蜀铲。由于這樣的重定向是臨時的边琉,客戶端應當繼續(xù)向原有地址發(fā)送以后的請求。只有在Cache-Control或Expires中進行了指定的情況下记劝,這個響應才是可緩存的变姨。   新的臨時性的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求厌丑,否則響應的實體中應當包含指向新的 URI 的超鏈接及簡短說明定欧。   如果這不是一個 GET 或者 HEAD 請求,那么瀏覽器禁止自動進行重定向蹄衷,除非得到用戶的確認忧额,因為請求的條件可能因此發(fā)生變化。   注意:雖然RFC 1945和RFC 2068規(guī)范不允許客戶端在重定向時改變請求的方法愧口,但是很多現(xiàn)存的瀏覽器將302響應視作為303響應睦番,并且使用 GET 方式訪問在 Location 中規(guī)定的 URI,而無視原先請求的方法耍属。狀態(tài)碼303和307被添加了進來托嚣,用以明確服務器期待客戶端進行何種反應。
303 對應當前請求的響應可以在另一個 URI 上被找到厚骗,而且客戶端應當采用 GET 的方式訪問那個資源示启。這個方法的存在主要是為了允許由腳本激活的POST請求輸出重定向到一個新的資源。這個新的 URI 不是原始資源的替代引用领舰。同時夫嗓,303響應禁止被緩存。當然冲秽,第二個請求(重定向)可能被緩存舍咖。   新的 URI 應當在響應的 Location 域中返回。除非這是一個 HEAD 請求锉桑,否則響應的實體中應當包含指向新的 URI 的超鏈接及簡短說明排霉。   注意:許多 HTTP/1.1 版以前的 瀏覽器不能正確理解303狀態(tài)。如果需要考慮與這些瀏覽器之間的互動民轴,302狀態(tài)碼應該可以勝任攻柠,因為大多數(shù)的瀏覽器處理302響應時的方式恰恰就是上述規(guī)范要求客戶端處理303響應時應當做的球订。
304 如果客戶端發(fā)送了一個帶條件的 GET 請求且該請求已被允許,而文檔的內容(自上次訪問以來或者根據(jù)請求的條件)并沒有改變瑰钮,則服務器應當返回這個狀態(tài)碼冒滩。304響應禁止包含消息體,因此始終以消息頭后的第一個空行結尾浪谴。   該響應必須包含以下的頭信息:   Date旦部,除非這個服務器沒有時鐘。假如沒有時鐘的服務器也遵守這些規(guī)則较店,那么代理服務器以及客戶端可以自行將 Date 字段添加到接收到的響應頭中去(正如RFC 2068中規(guī)定的一樣),緩存機制將會正常工作容燕。   ETag 和/或 Content-Location梁呈,假如同樣的請求本應返回200響應。   Expires, Cache-Control蘸秘,和/或Vary官卡,假如其值可能與之前相同變量的其他響應對應的值不同的話。   假如本響應請求使用了強緩存驗證醋虏,那么本次響應不應該包含其他實體頭寻咒;否則(例如,某個帶條件的 GET 請求使用了弱緩存驗證)颈嚼,本次響應禁止包含其他實體頭毛秘;這避免了緩存了的實體內容和更新了的實體頭信息之間的不一致。   假如某個304響應指明了當前某個實體沒有緩存阻课,那么緩存系統(tǒng)必須忽視這個響應叫挟,并且重復發(fā)送不包含限制條件的請求。   假如接收到一個要求更新某個緩存條目的304響應限煞,那么緩存系統(tǒng)必須更新整個條目以反映所有在響應中被更新的字段的值抹恳。
305 被請求的資源必須通過指定的代理才能被訪問。Location 域中將給出指定的代理所在的 URI 信息署驻,接收者需要重復發(fā)送一個單獨的請求奋献,通過這個代理才能訪問相應資源。只有原始服務器才能建立305響應旺上。   注意:RFC 2068中沒有明確305響應是為了重定向一個單獨的請求瓶蚂,而且只能被原始服務器建立。忽視這些限制可能導致嚴重的安全后果抚官。
306 在最新版的規(guī)范中扬跋,306狀態(tài)碼已經不再被使用。
307 請求的資源現(xiàn)在臨時從不同的URI 響應請求凌节。由于這樣的重定向是臨時的钦听,客戶端應當繼續(xù)向原有地址發(fā)送以后的請求洒试。只有在Cache-Control或Expires中進行了指定的情況下,這個響應才是可緩存的朴上。   新的臨時性的URI 應當在響應的 Location 域中返回垒棋。除非這是一個HEAD 請求,否則響應的實體中應當包含指向新的URI 的超鏈接及簡短說明痪宰。因為部分瀏覽器不能識別307響應叼架,因此需要添加上述必要信息以便用戶能夠理解并向新的 URI 發(fā)出訪問請求。   如果這不是一個GET 或者 HEAD 請求衣撬,那么瀏覽器禁止自動進行重定向乖订,除非得到用戶的確認,因為請求的條件可能因此發(fā)生變化具练。
400 1乍构、語義有誤,當前請求無法被服務器理解扛点。除非進行修改哥遮,否則客戶端不應該重復提交這個請求。   2陵究、請求參數(shù)有誤眠饮。
401 當前請求需要用戶驗證。該響應必須包含一個適用于被請求資源的 WWW-Authenticate 信息頭用以詢問用戶信息铜邮∫钦伲客戶端可以重復提交一個包含恰當?shù)?Authorization 頭信息的請求。如果當前請求已經包含了 Authorization 證書松蒜,那么401響應代表著服務器驗證已經拒絕了那些證書返咱。如果401響應包含了與前一個響應相同的身份驗證詢問,且瀏覽器已經至少嘗試了一次驗證牍鞠,那么瀏覽器應當向用戶展示響應中包含的實體信息咖摹,因為這個實體信息中可能包含了相關診斷信息。參見RFC 2617难述。
402 該狀態(tài)碼是為了將來可能的需求而預留的萤晴。
403 服務器已經理解請求,但是拒絕執(zhí)行它胁后。與401響應不同的是店读,身份驗證并不能提供任何幫助,而且這個請求也不應該被重復提交攀芯。如果這不是一個 HEAD 請求屯断,而且服務器希望能夠講清楚為何請求不能被執(zhí)行,那么就應該在實體內描述拒絕的原因。當然服務器也可以返回一個404響應殖演,假如它不希望讓客戶端獲得任何信息氧秘。
404 請求失敗,請求所希望得到的資源未被在服務器上發(fā)現(xiàn)趴久。沒有信息能夠告訴用戶這個狀況到底是暫時的還是永久的丸相。假如服務器知道情況的話,應當使用410狀態(tài)碼來告知舊資源因為某些內部的配置機制問題彼棍,已經永久的不可用灭忠,而且沒有任何可以跳轉的地址。404這個狀態(tài)碼被廣泛應用于當服務器不想揭示到底為何請求被拒絕或者沒有其他適合的響應可用的情況下座硕。
405 請求行中指定的請求方法不能被用于請求相應的資源弛作。該響應必須返回一個Allow 頭信息用以表示出當前資源能夠接受的請求方法的列表。   鑒于 PUT华匾,DELETE 方法會對服務器上的資源進行寫操作缆蝉,因而絕大部分的網頁服務器都不支持或者在默認配置下不允許上述請求方法,對于此類請求均會返回405錯誤瘦真。
406 請求的資源的內容特性無法滿足請求頭中的條件,因而無法生成響應實體黍瞧。   除非這是一個 HEAD 請求诸尽,否則該響應就應當返回一個包含可以讓用戶或者瀏覽器從中選擇最合適的實體特性以及地址列表的實體。實體的格式由 Content-Type 頭中定義的媒體類型決定印颤。瀏覽器可以根據(jù)格式及自身能力自行作出最佳選擇您机。但是,規(guī)范中并沒有定義任何作出此類自動選擇的標準年局。
407  與401響應類似际看,只不過客戶端必須在代理服務器上進行身份驗證。代理服務器必須返回一個 Proxy-Authenticate 用以進行身份詢問矢否≈倜觯客戶端可以返回一個 Proxy-Authorization 信息頭用以驗證。參見RFC 2617僵朗。
408 請求超時赖欣。客戶端沒有在服務器預備等待的時間內完成一個請求的發(fā)送验庙《ニ保客戶端可以隨時再次提交這一請求而無需進行任何更改。
409 由于和被請求的資源的當前狀態(tài)之間存在沖突粪薛,請求無法完成悴了。這個代碼只允許用在這樣的情況下才能被使用:用戶被認為能夠解決沖突,并且會重新提交新的請求。該響應應當包含足夠的信息以便用戶發(fā)現(xiàn)沖突的源頭湃交。   沖突通常發(fā)生于對 PUT 請求的處理中熟空。例如,在采用版本檢查的環(huán)境下巡揍,某次 PUT 提交的對特定資源的修改請求所附帶的版本信息與之前的某個(第三方)請求向沖突痛阻,那么此時服務器就應該返回一個409錯誤,告知用戶請求無法完成腮敌。此時阱当,響應實體中很可能會包含兩個沖突版本之間的差異比較,以便用戶重新提交歸并以后的新版本糜工。
410 被請求的資源在服務器上已經不再可用弊添,而且沒有任何已知的轉發(fā)地址。這樣的狀況應當被認為是永久性的捌木。如果可能油坝,擁有鏈接編輯功能的客戶端應當在獲得用戶許可后刪除所有指向這個地址的引用。如果服務器不知道或者無法確定這個狀況是否是永久的刨裆,那么就應該使用404狀態(tài)碼澈圈。除非額外說明,否則這個響應是可緩存的帆啃。   410響應的目的主要是幫助網站管理員維護網站瞬女,通知用戶該資源已經不再可用,并且服務器擁有者希望所有指向這個資源的遠端連接也被刪除努潘。這類事件在限時诽偷、增值服務中很普遍。同樣疯坤,410響應也被用于通知客戶端在當前服務器站點上报慕,原本屬于某個個人的資源已經不再可用。當然压怠,是否需要把所有永久不可用的資源標記為'410 Gone'眠冈,以及是否需要保持此標記多長時間,完全取決于服務器擁有者菌瘫。
411 服務器拒絕在沒有定義 Content-Length 頭的情況下接受請求洋闽。在添加了表明請求消息體長度的有效 Content-Length 頭之后,客戶端可以再次提交該請求突梦。
412 服務器在驗證在請求的頭字段中給出先決條件時诫舅,沒能滿足其中的一個或多個。這個狀態(tài)碼允許客戶端在獲取資源時在請求的元信息(請求頭字段數(shù)據(jù))中設置先決條件宫患,以此避免該請求方法被應用到其希望的內容以外的資源上刊懈。
413 服務器拒絕處理當前請求,因為該請求提交的實體數(shù)據(jù)大小超過了服務器愿意或者能夠處理的范圍。此種情況下虚汛,服務器可以關閉連接以免客戶端繼續(xù)發(fā)送此請求匾浪。   如果這個狀況是臨時的,服務器應當返回一個 Retry-After 的響應頭卷哩,以告知客戶端可以在多少時間以后重新嘗試蛋辈。
414 請求的URI 長度超過了服務器能夠解釋的長度,因此服務器拒絕對該請求提供服務将谊。這比較少見冷溶,通常的情況包括:   本應使用POST方法的表單提交變成了GET方法,導致查詢字符串(Query String)過長尊浓。   重定向URI “黑洞”逞频,例如每次重定向把舊的 URI 作為新的 URI 的一部分,導致在若干次重定向后 URI 超長栋齿。   客戶端正在嘗試利用某些服務器中存在的安全漏洞攻擊服務器苗胀。這類服務器使用固定長度的緩沖讀取或操作請求的 URI,當 GET 后的參數(shù)超過某個數(shù)值后瓦堵,可能會產生緩沖區(qū)溢出基协,導致任意代碼被執(zhí)行[1]。沒有此類漏洞的服務器菇用,應當返回414狀態(tài)碼澜驮。
415 對于當前請求的方法和所請求的資源,請求中提交的實體并不是服務器中所支持的格式刨疼,因此請求被拒絕。
416 如果請求中包含了 Range 請求頭鹅龄,并且 Range 中指定的任何數(shù)據(jù)范圍都與當前資源的可用范圍不重合揩慕,同時請求中又沒有定義 If-Range 請求頭,那么服務器就應當返回416狀態(tài)碼扮休。   假如 Range 使用的是字節(jié)范圍迎卤,那么這種情況就是指請求指定的所有數(shù)據(jù)范圍的首字節(jié)位置都超過了當前資源的長度。服務器也應當在返回416狀態(tài)碼的同時玷坠,包含一個 Content-Range 實體頭蜗搔,用以指明當前資源的長度。這個響應也被禁止使用 multipart/byteranges 作為其 Content-Type八堡。
417 在請求頭 Expect 中指定的預期內容無法被服務器滿足樟凄,或者這個服務器是一個代理服務器,它有明顯的證據(jù)證明在當前路由的下一個節(jié)點上兄渺,Expect 的內容無法被滿足缝龄。
421 從當前客戶端所在的IP地址到服務器的連接數(shù)超過了服務器許可的最大范圍。通常,這里的IP地址指的是從服務器上看到的客戶端地址(比如用戶的網關或者代理服務器地址)叔壤。在這種情況下瞎饲,連接數(shù)的計算可能涉及到不止一個終端用戶。
422 從當前客戶端所在的IP地址到服務器的連接數(shù)超過了服務器許可的最大范圍炼绘。通常嗅战,這里的IP地址指的是從服務器上看到的客戶端地址(比如用戶的網關或者代理服務器地址)。在這種情況下俺亮,連接數(shù)的計算可能涉及到不止一個終端用戶驮捍。
422 請求格式正確,但是由于含有語義錯誤铅辞,無法響應厌漂。(RFC 4918 WebDAV)423 Locked   當前資源被鎖定。(RFC 4918 WebDAV)
424 由于之前的某個請求發(fā)生的錯誤斟珊,導致當前請求失敗苇倡,例如 PROPPATCH。(RFC 4918 WebDAV)
425 在WebDav Advanced Collections 草案中定義囤踩,但是未出現(xiàn)在《WebDAV 順序集協(xié)議》(RFC 3658)中旨椒。
426 客戶端應當切換到TLS/1.0。(RFC 2817)
449 由微軟擴展堵漱,代表請求應當在執(zhí)行完適當?shù)牟僮骱筮M行重試综慎。
500 服務器遇到了一個未曾預料的狀況,導致了它無法完成對請求的處理勤庐。一般來說示惊,這個問題都會在服務器的程序碼出錯時出現(xiàn)。
501 服務器不支持當前請求所需要的某個功能愉镰。當服務器無法識別請求的方法米罚,并且無法支持其對任何資源的請求。
502 作為網關或者代理工作的服務器嘗試執(zhí)行請求時丈探,從上游服務器接收到無效的響應录择。
503 由于臨時的服務器維護或者過載,服務器當前無法處理請求碗降。這個狀況是臨時的隘竭,并且將在一段時間以后恢復。如果能夠預計延遲時間讼渊,那么響應中可以包含一個 Retry-After 頭用以標明這個延遲時間动看。如果沒有給出這個 Retry-After 信息,那么客戶端應當以處理500響應的方式處理它爪幻。   注意:503狀態(tài)碼的存在并不意味著服務器在過載的時候必須使用它弧圆。某些服務器只不過是希望拒絕客戶端的連接赋兵。
504 作為網關或者代理工作的服務器嘗試執(zhí)行請求時,未能及時從上游服務器(URI標識出的服務器搔预,例如HTTP霹期、FTP、LDAP)或者輔助服務器(例如DNS)收到響應拯田。   注意:某些代理服務器在DNS查詢超時時會返回400或者500錯誤
505 服務器不支持历造,或者拒絕支持在請求中使用的 HTTP 版本。這暗示著服務器不能或不愿使用與客戶端相同的版本船庇。響應中應當包含一個描述了為何版本不被支持以及服務器支持哪些協(xié)議的實體吭产。
506 由《透明內容協(xié)商協(xié)議》(RFC 2295)擴展,代表服務器存在內部配置錯誤:被請求的協(xié)商變元資源被配置為在透明內容協(xié)商中使用自己鸭轮,因此在一個協(xié)商處理中不是一個合適的重點臣淤。
507 服務器無法存儲完成請求所必須的內容。這個狀況被認為是臨時的窃爷。WebDAV (RFC 4918)
509 服務器達到帶寬限制邑蒋。這不是一個官方的狀態(tài)碼,但是仍被廣泛使用按厘。
510 獲取資源所需要的策略并沒有沒滿足医吊。(RFC 2774)

[參考鏈接] (http://tools.jb51.net/table/http_status_code )

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市逮京,隨后出現(xiàn)的幾起案子卿堂,更是在濱河造成了極大的恐慌,老刑警劉巖懒棉,帶你破解...
    沈念sama閱讀 206,013評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件草描,死亡現(xiàn)場離奇詭異,居然都是意外死亡策严,警方通過查閱死者的電腦和手機穗慕,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,205評論 2 382
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來享钞,“玉大人揍诽,你說我怎么就攤上這事诀蓉±跏” “怎么了?”我有些...
    開封第一講書人閱讀 152,370評論 0 342
  • 文/不壞的土叔 我叫張陵渠啤,是天一觀的道長狐肢。 經常有香客問我,道長沥曹,這世上最難降的妖魔是什么份名? 我笑而不...
    開封第一講書人閱讀 55,168評論 1 278
  • 正文 為了忘掉前任碟联,我火速辦了婚禮,結果婚禮上僵腺,老公的妹妹穿的比我還像新娘鲤孵。我一直安慰自己,他們只是感情好辰如,可當我...
    茶點故事閱讀 64,153評論 5 371
  • 文/花漫 我一把揭開白布普监。 她就那樣靜靜地躺著,像睡著了一般琉兜。 火紅的嫁衣襯著肌膚如雪凯正。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 48,954評論 1 283
  • 那天豌蟋,我揣著相機與錄音廊散,去河邊找鬼。 笑死梧疲,一個胖子當著我的面吹牛允睹,可吹牛的內容都是我干的。 我是一名探鬼主播往声,決...
    沈念sama閱讀 38,271評論 3 399
  • 文/蒼蘭香墨 我猛地睜開眼擂找,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了浩销?” 一聲冷哼從身側響起贯涎,我...
    開封第一講書人閱讀 36,916評論 0 259
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎慢洋,沒想到半個月后塘雳,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經...
    沈念sama閱讀 43,382評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡普筹,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 35,877評論 2 323
  • 正文 我和宋清朗相戀三年败明,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片太防。...
    茶點故事閱讀 37,989評論 1 333
  • 序言:一個原本活蹦亂跳的男人離奇死亡妻顶,死狀恐怖,靈堂內的尸體忽然破棺而出蜒车,到底是詐尸還是另有隱情讳嘱,我是刑警寧澤,帶...
    沈念sama閱讀 33,624評論 4 322
  • 正文 年R本政府宣布酿愧,位于F島的核電站沥潭,受9級特大地震影響,放射性物質發(fā)生泄漏嬉挡。R本人自食惡果不足惜钝鸽,卻給世界環(huán)境...
    茶點故事閱讀 39,209評論 3 307
  • 文/蒙蒙 一汇恤、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧拔恰,春花似錦因谎、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,199評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至饭冬,卻和暖如春使鹅,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背昌抠。 一陣腳步聲響...
    開封第一講書人閱讀 31,418評論 1 260
  • 我被黑心中介騙來泰國打工患朱, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人炊苫。 一個月前我還...
    沈念sama閱讀 45,401評論 2 352
  • 正文 我出身青樓裁厅,卻偏偏與公主長得像,于是被迫代替她去往敵國和親侨艾。 傳聞我的和親對象是個殘疾皇子执虹,可洞房花燭夜當晚...
    茶點故事閱讀 42,700評論 2 345

推薦閱讀更多精彩內容

  • HTTP狀態(tài)碼(HTTP Status Code)表示http服務器對與請求HTTP響應狀態(tài)的3位數(shù)字代碼。它由 ...
    BeeNoisy閱讀 1,756評論 0 8
  • 1xx消息 這一類型的狀態(tài)碼,代表請求已被接受,需要繼續(xù)處理唠梨。這類響應是臨時響應,只包含狀態(tài)行和某些可選的響應頭信...
    帥陽閱讀 402評論 0 0
  • 摘自 wiki HTTP狀態(tài)碼 1xx消息 這一類型的狀態(tài)碼袋励,代表請求已被接受,需要繼續(xù)處理当叭。這類響應是臨時響應茬故,...
    SincereDu閱讀 250評論 0 1
  • 1xx消息 這一類型的狀態(tài)碼,代表請求已被接受蚁鳖,需要繼續(xù)處理磺芭。這類響應是臨時響應,只包含狀態(tài)行和某些可選的響應頭信...
    輪回小飛飛閱讀 234評論 0 0
  • 1xx消息 這一類型的狀態(tài)碼醉箕,代表請求已被接受钾腺,需要繼續(xù)處理。這類響應是臨時響應讥裤,只包含狀態(tài)行和某些可選的響應頭信...
    執(zhí)著的小蛋撻閱讀 146評論 0 0