前端基礎:HTTP 狀態碼詳解

HTTP 狀態碼詳解

1xx(信息類):表示接收到請求並繼續處理瀏覽器

100 客戶端應當繼續發送請求。這個臨時響應是用來通知客戶端他的部分請求已經被服務器接收,且仍未被拒絕。客戶端應當繼續發送請求的剩餘部分,或者若是請求已經完成,忽略這個響應。服務器必須在請求完成後向客戶端發送一個最終響應。

101 服務器已經理解了客戶端的請求,並將經過upgrade消息頭通知客戶端採用不一樣的協議來完成這個請求。在發送這個響應最後的空行後,服務器將會切換到在upgrade消息頭中定義的那些協議。只有在切換新的協議更有好處的時候才應該採起此類措施。例如,切換到新的HTTP版本比舊版本更有優點,或者切換到一個實時同步的協議以傳送利用此類特性的資源。

2xx(相應成功):標識動做被成功接收、理解和處理緩存

200 請求已經成功,請求所但願的響應頭或數據體將隨此響應返回。

201 請求已經被實現,且又一個新的資源已經以據請求的須要而創建,且其URI已經隨Location頭信息返回。若是須要的資源沒法及時創建的話,應當返回"202 Accepted"。

202 服務器已接受請求,但還沒有處理。正如它可能被拒絕同樣,最終該請求可能會也可能不會被執行。在異步操做的場合下,沒有比發送這個狀態碼更方便的作法了。返回202狀態碼響應的目的是容許服務器接受其餘過程的請求(例如,某個天天只執行一次的基於批處理的操做),而沒必要讓客戶端一直保持與服務器的鏈接直到批處理操做所有完成。在接受請求處理並返回202狀態碼的響應應當在返回的實體中包含一些指示處理當前狀態的信息,以及指向處理狀態監視器或狀態預測的指針,以便用戶可以估計操做是否已經完成。

203 服務器已經成功處理了請求,但返回的實體頭部元信息不是在原始服務器上有效的肯定集合,而是來自本地或者第三方的拷貝。當親的信息多是原始版本的子集或超集。例如,包含資源的元數據可能致使原始服務器知道元信息的超集。使用此狀態碼不是必須的,並且只有在響應不使用此狀態碼便會返回200 OK的狀況下才是合適的。

204 服務器成功處理了請求,但不須要返回任何實體內容,而且但願返回更新了的元信息。響應可能經過實體頭部的形式,返回新的或更新後的元信息。若是存在這些頭部信息,澤應當與所請求的變量相呼應。若是客戶端是瀏覽器的話,那麼用戶瀏覽器應保留髮送了該請求的頁面,而不產生任何文檔視圖上的變化,即便按照規範新的或更新後的元信息應當被應用到用戶瀏覽器活動視圖中的文檔。因爲204響應被禁止包含任何實體,所以它始終以消息頭後的第一個空行結尾。

205 服務器成功處理了請求,且沒有任何返回內容。可是與204響應不一樣,返回此狀態碼的響應要求請求者重置文檔視圖。該響應主要是被用於接受用戶輸入後,當即重置表單,以便用戶可以輕鬆地開始另外一次輸入。與204響應同樣,該響應也被禁止包含任何消息體,且以消息頭後的第一個空行結束。

206 服務器已經成功處理了部分GET請求。相似於FlashGet或迅雷這類HTTP下載工具都是使用此類響應實現斷點續傳或將一個大文檔分解爲多個下載段同時下載。該請求必須包含Range頭信息來指示客戶端但願獲得的內容範圍,而且可能包含If-Range來做爲請求條件。響應必須包含以下的頭部域:
Content-Range 用以指示本次響應中返回內容的範圍;若是是Content-Type爲multipart/byteranges的多段下載,則每一multipart段中都應包含Content-Range域用以指示本段的內容範圍。假如響應中包含Content-Length,那麼它的數值必須匹配它返回的內容範圍的真實字節數。

3xx(重定向類):爲了完成指定的動做,必須接受進一步處理服務器

300 被請求的資源有一系列可供選擇的回饋信息,每一個都有本身特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器可以自行選擇已給首選的地址進行重定向。除非這是一個HEAD請求,不然該響應應當包括一個資源特性及地址的列表實體,以便用戶或瀏覽器從中選擇最合適的重定向地址。這個實體的格式由Content-Type定義的格式所決定。瀏覽器可能根據響應的格式以及瀏覽器自身能力,自動作出最合適的選擇。若是服務器自己已經有了首選的回饋選擇,那麼在Location中應當指明這個回饋的URI;瀏覽器可能會將這個Location值做爲自動重定向的地址。此外,除非額外指定,不然這個響應也是可緩存的。

301 被請求的資源已被永久移到新位置,而且未來任何對此資源的引用都應該使用本響應返回的若干個URI之一。若是可能,擁有連接編輯功能的客戶端應當自動把請求的地址修改成從服務器反饋回來的地址。除非額外指定,不然這個響應也是可緩存的。新的永久性的URI應當在響應的Location域中返回,除非這是一個HEAD請求,不然響應的實體中應當包含指向新的URI的超連接及簡短說明。若是這不是一個GET或HEAD請求,瀏覽器禁止自動進行重定向,除非獲得用戶的確認,由於請求的條件可能所以發生變化。

302 請求的資源如今臨時從不一樣的URI響應請求。因爲這樣的重定向是臨時的,客戶端應當繼續向原有地址發送之後的請求。只有在Cache-Control或Expires中進行了指定的狀況下,這個響應纔是可緩存的。新的臨時性的URI應當在響應的Location域中返回,除非這是一個HEAD請求,不然響應的實體中應當包含指向新的URI的超連接及簡短說明。若是這不是一個GET或HEAD請求,瀏覽器禁止自動進行重定向,除非獲得用戶的確認,由於請求的條件可能所以發生變化。

303 對應當前請求的響應能夠在另外一個URI上被找到,並且客戶端應當採用GET的方式訪問那個資源。這個方法的存在主要是爲了容許由腳本激活的POST請求輸出重定向到一個顯得資源。這個新的URI不是原始資源的替代引用。同時,303響應禁止被緩存。固然,第二個請求(重定向)可能被緩存。新的URI應當在響應的Location域中返回,除非這時一個HEAD請求,不然響應的實體中應當包含指向新的URI的超連接及簡短說明。

304 若是客戶端發送了一個待條件的GET請求且該請求以被容許,而文檔的內容(自上次訪問以來或根據請求的條件)並無改變,則服務器應當返回這個狀態碼。304響應禁止包含消息體,所以始終以消息頭後的第一個空行結尾。

305 被請求的資源必須經過指定的代理才能被訪問。Location域中將給出指定的代理所在的URI信息,接收者須要重複發送一個單獨的請求,經過這個代理才能訪問相應資源,只有原始服務器才能創建305響應。
306 在最新的規範中,306狀態碼已經再也不被使用。

307 請求的資源如今臨時從不一樣的URI響應請求,因爲這樣的重定向是臨時的,客戶端應當繼續向原有地址發送之後的請求。只有在Cache-Control或Expires中進行了指定的狀況下,這個響應纔是可緩存的。新的臨時性URI應當在響應的Location域中返回,除非這是一個HEAD請求,不然響應的實體中應當包含新的URI的超連接及簡短說明。由於部分瀏覽器不能識別307響應,所以須要添加上述必要信息以便用戶可以理解並向新的URI發出訪問請求。若是這不是一個GET或HEAD請求,那麼瀏覽器禁止自動進行重定向,除非獲得用戶的確認,由於請求的條件可能所以發生變化。

4xx(客戶端錯誤類):請求包含錯誤語法或不能正確執行異步

400 語義有誤,當前請求沒法被服務器理解,除非進行修改,不然客戶端不該該重複提交這個請求;請求參數有誤。

401 當前請求須要用戶驗證。

402 該狀態碼是爲了未來可能的需求而預留的。

403 服務器已經理解請求,但拒絕執行它。與401響應不一樣的是,身份驗證並不能提供任何幫助,並且這個請求也不該該被重複提交。

404 請求失敗,請求所但願獲得的資源未被在服務器上發現。沒有信息可以告訴用戶這個狀態究竟是暫時的仍是永久的。假如服務器知道狀況的話,應當使用410狀態碼來告知舊資源由於某些內部的配置機制問題,已經永久的不可用,並且沒有任何可跳轉的地址。404這個狀態碼被普遍用於當服務器不想揭示到底爲什麼請求被拒絕或沒有其餘適合的響應可用的狀況下。

405 請求行中指定的請求方法不能被用於請求相應的資源。該響應必須返回一個Allow頭信息用以表示出當前資源可以接受的請求方法的列表。鑑於PUT,DELETE方法會對服務器上的資源進行寫操做,由於絕大部分的網頁服務器都不支持或在默認配置下不容許上述請求方法,對於此類請求均會返回405錯誤。

406 請求資源的內容特性沒法知足請求頭中的條件,由於沒法生成響應實體。除非這是一個HEAD請求,不然該響應就應當返回一個包含可讓用戶或者瀏覽器從中選擇最合適的實體特性以及地址列表實體。實體的格式由Content-Type頭中定義的媒體類型決定。瀏覽器能夠根據格式及自身能力自行作出最佳選擇。可是,規範中並無定義任何做出此類自動選擇的標準。

407 與401響應相似,只不過客戶端必須在代理服務器上進行身份驗證。代理服務器必須返回一個Proxy-Authenticate用以進行身份詢問。客戶端能夠返回一個Proxy-Authorization信息頭用於驗證。

408 請求超時,客戶端沒有在服務器預設的等待時間內完成一個請求發送。客戶端能夠隨時再次提交這一請求無需進行任何更改。

409 因爲和被請求的資源的當前狀態之間存在衝突,請求沒法完成。該狀態碼的使用狀況:用戶被認爲可以解決衝突,而且會從新提交新的請求。該響應應當包含足夠的信息以便用戶發現衝突的源頭。衝突一般發生對於PUT請求的處理中。

410 被請求的資源在服務器上已經再也不可用,並且沒有任何已知的轉發地址。這樣的情況應該被認爲是永久性的。若是可能,擁有連接編輯功能的客戶端應當在得到用戶許可後刪除全部指向這個地址的引用。若是服務器不知道或沒法肯定這個情況是不是永久的,那麼就應該使用404狀態碼。除非額外說明,不然這個響應是可緩存的。410響應的主要目的是幫助網站管理員維護網站,通知用戶該資源已經不在可用,而且服務器擁有着但願全部指向這個資源的遠端連接也被刪除。這類事件在限時、增值服務中很廣泛。一樣,410響應也被用於通知客戶端在當前服務站點上,本來屬於某個我的的資源已經再也不可用。固然是否須要把全部永久不可用的資源標記爲"410 Gone",以及是否須要保持此標記多長時間,徹底取決於服務器擁有者。

411 服務器拒絕在沒有定義Conten-Length頭的狀況下接受請求。在添加了代表請求消息體長度的有效Content-Length頭以後,客戶端能夠再次提交該請求。

412 服務器在驗證請求頭字段中給出先決條件時,沒能知足其中的一個或多個。這個狀態碼容許客戶端在獲取資源時在請求的元信息(請求頭字段數據)中設置先決條件,以此避免該請求方法被應用到其但願的內容之外的資源上。

413 服務器拒絕處理前請求,由於該請求提交的實體數據超過了服務器願意或可以處理的範圍。此種狀況下,服務器能夠關閉鏈接以避免客戶端繼續發送此請求。

414 請求的URI長度超過了服務器可以解釋的長度,所以服務器拒絕對該請求提供服務,比較少見。

415 對於當前球的方法和所請求的資源,請求中提交的實體並非服務器中所支持的格式,所以請求被拒絕。

416 若是請求中包含了Range請求頭,而且Range中指定的任何數據範圍都與當前資源的可用範圍補充和,同時請求中又沒有定義If-Range請求頭,那麼服務器就應當返回416狀態碼。

417 在請求頭Except中指定的預期內容沒法被服務器知足,或服務器是個代理服務器,它有明顯的證據證實在當前路由的下一個節點上,Except的內容沒法被知足。

5xx(服務端錯誤類):服務器不能正確執行一個正確的請求工具

500 服務器遇到了一個不曾預料到情況,致使了它沒法完成對請求的處理。通常來講,這個問題都會在服務器的程序碼出錯時出現。

501 服務器不支持當請求所須要的某個功能,當服務器沒法識別請求的方法,而且沒法支持其對任何資源的請求。

502 做爲網關或者代理工做的服務器嘗試執行請求時,從上游服務器接收到無效的響應。

503 因爲臨時的服務器維護或過載,服務器當前沒法處理請求。這個情況是臨時的,而且將在一段時間以後恢復。若是可以預計延遲時間,那麼響應中能夠包含一個Retry-After頭用以標明這個延遲時間,若是沒有給出這個Retry-After信息,那麼客戶端當以處理500響應方式處理它。

504 做爲網關或代理服務器嘗試執行請求時,未能及時從上有服務器或輔助服務器收到響應。

505 服務器不支持,或拒絕支持在請求中使用的HTTP版本。這暗示着服務器不能或不肯使用與客戶端相同的版本。響應中應當包含一個描述了爲什麼版本不被支持以及服務器支持哪些協議的實體。

506 由《透明內容協商協議》擴展,表明服務器存在內部配置錯誤。

507 服務器沒法存儲完成請求所必須的內容。這個狀態被認爲是臨時的。

509 服務器達到帶寬限制。這不是一個官方的狀態碼,但仍被普遍使用。

510 獲取資源所須要的策略並無知足。
相關文章
相關標籤/搜索