前端關注的瀏覽器狀態碼

2021-07-26 20:48:24 字數 4019 閱讀 2780

這一型別的狀態碼,代表請求已被接受,需要繼續處理。這類響應是臨時響應,只包含狀態行和某些可選的響應頭資訊,並以空行結束。由於 http/1.0 協議中沒有定義任何 1xx 狀態碼,所以除非在某些試驗條件下,伺服器禁止向此類客戶端傳送 1xx 響應。

100 continue

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

101 switching protocols

伺服器已經理解了客戶端的請求,並將通過upgrade 訊息頭通知客戶端採用不同的協議來完成這個請求。在傳送完這個響應最後的空行後,伺服器將會切換到在upgrade 訊息頭中定義的那些協議。

這一型別的狀態碼,代表請求已成功被伺服器接收、理解、並接受[1] 。

200 ok

請求已成功,請求所希望的響應頭或資料體將隨此響應返回。

206 partial content這類狀態碼代表需要客戶端採取進一步的操作才能完成請求。通常,這些狀態碼用來重定向,後續的請求位址(重定向目標)在本次響應的 location 域中指明。

當且僅當後續的請求所使用的方法是 get 或者 head 時,使用者瀏覽器才可以在沒有使用者介入的情況下自動提交所需要的後續請求。客戶端應當自動監測無限迴圈重定向(例如:a->a,或者a->b->c->a),因為這會導致伺服器和客戶端大量不必要的資源消耗。按照 http/1.0 版規範的建議,瀏覽器不應自動訪問超過5次的重定向。

301 moved permanently

被請求的資源已永久移動到新位置,並且將來任何對此資源的引用都應該使用本響應返回的若干個 uri 之一。如果可能,擁有鏈結編輯功能的客戶端應當自動把請求的位址修改為從伺服器反饋回來的位址。除非額外指定,否則這個響應也是可快取的。

新的永久性的uri 應當在響應的 location 域中返回。除非這是乙個 head 請求,否則響應的實體中應當包含指向新的 uri 的超連結及簡短說明。

如果這不是乙個 get 或者 head 請求,因此瀏覽器禁止自動進行重定向,除非得到使用者的確認,因為請求的條件可能因此發生變化。

注意:對於某些使用 http/1.0 協議的瀏覽器,當它們傳送的 post 請求得到了乙個301響應的話,接下來的重定向請求將會變成 get 方式。

302 move temporarily

請求的資源臨時從不同的 uri響應請求。由於這樣的重定向是臨時的,客戶端應當繼續向原有位址傳送以後的請求。只有在cache-control或expires中進行了指定的情況下,這個響應才是可快取的。

上文有提及。

如果這不是乙個 get 或者 head 請求,那麼瀏覽器禁止自動進行重定向,除非得到使用者的確認,因為請求的條件可能因此發生變化。

注意:雖然rfc 1945和rfc 2068規範不允許客戶端在重定向時改變請求的方法,但是很多現存的瀏覽器將302響應視作為303響應,並且使用 get 方式訪問在 location 中規定的 uri,而無視原先請求的方法。狀態碼303和307被新增了進來,用以明確伺服器期待客戶端進行何種反應。

304 not modified

如果客戶端傳送了乙個帶條件的 get 請求且該請求已被允許,而文件的內容(自上次訪問以來或者根據請求的條件)並沒有改變,則伺服器應當返回這個狀態碼。304響應禁止包含訊息體,因此始終以訊息頭後的第乙個空行結尾。

該響應必須包含以下的頭資訊:

date,除非這個伺服器沒有時鐘。假如沒有時鐘的伺服器也遵守這些規則,那麼**伺服器以及客戶端可以自行將 date 字段新增到接收到的響應頭中去(正如rfc 2068中規定的一樣),快取機制將會正常工作。

etag 和/或 content-location,假如同樣的請求本應返回200響應。

expires, cache-control,和/或vary,假如其值可能與之前相同變數的其他響應對應的值不同的話。

假如本響應請求使用了強快取驗證,那麼本次響應不應該包含其他實體頭;否則(例如,某個帶條件的 get 請求使用了弱快取驗證),本次響應禁止包含其他實體頭;這避免了快取了的實體內容和更新了的實體頭資訊之間的不一致。

假如某個304響應指明了當前某個實體沒有快取,那麼快取系統必須忽視這個響應,並且重**送不包含限制條件的請求。

假如接收到乙個要求更新某個快取條目的304響應,那麼快取系統必須更新整個條目以反映所有在響應中被更新的字段的值。

307 temporary redirect

請求的資源臨時從不同的uri 響應請求。

新的臨時性的uri 應當在響應的 location 域中返回。除非這是乙個head 請求,否則響應的實體中應當包含指向新的uri 的超連結及簡短說明。因為部分瀏覽器不能識別307響應,因此需要新增上述必要資訊以便使用者能夠理解並向新的 uri 發出訪問請求。

如果這不是乙個get 或者 head 請求,那麼瀏覽器禁止自動進行重定向,除非得到使用者的確認,因為請求的條件可能因此發生變化。

這類的狀態碼代表了客戶端看起來可能發生了錯誤,妨礙了伺服器的處理。除非響應的是乙個 head 請求,否則伺服器就應該返回乙個解釋當前錯誤狀況的實體,以及這是臨時的還是永久性的狀況。這些狀態碼適用於任何請求方法。瀏覽器應當向使用者顯示任何包含在此類錯誤響應中的實體內容。

如果錯誤發生時客戶端正在傳送資料,那麼使用tcp的伺服器實現應當仔細確保在關閉客戶端與伺服器之間的連線之前,客戶端已經收到了包含錯誤資訊的資料報。如果客戶端在收到錯誤資訊後繼續向伺服器傳送資料,伺服器的tcp棧將向客戶端傳送乙個重置資料報,以清除該客戶端所有還未識別的輸入緩衝,以免這些資料被伺服器上的應用程式讀取並干擾後者。

400 bad request

1、語義有誤,當前請求無法被伺服器理解。除非進行修改,否則客戶端不應該重複提交這個請求。

2、請求引數有誤。

401 unauthorized

當前請求需要使用者驗證。該響應必須包含乙個適用於被請求資源的 www-authenticate 資訊頭用以詢問使用者資訊。客戶端可以重複提交乙個包含恰當的 authorization 頭資訊的請求。如果當前請求已經包含了 authorization 證書,那麼401響應代表著伺服器驗證已經拒絕了那些證書。如果401響應包含了與前乙個響應相同的身份驗證詢問,且瀏覽器已經至少嘗試了一次驗證,那麼瀏覽器應當向使用者展示響應中包含的實體資訊,因為這個實體資訊中可能包含了相關診斷資訊。參見rfc 2617。

403 forbidden

伺服器已經理解請求,但是拒絕執行它。與401響應不同的是,身份驗證並不能提供任何幫助,而且這個請求也不應該被重複提交。如果這不是乙個 head 請求,而且伺服器希望能夠講清楚為何請求不能被執行,那麼就應該在實體內描述拒絕的原因。當然伺服器也可以返回乙個404響應,假如它不希望讓客戶端獲得任何資訊。

404 not found

請求失敗,請求所希望得到的資源未被在伺服器上發現。沒有資訊能夠告訴使用者這個狀況到底是暫時的還是永久的。假如伺服器知道情況的話,應當使用410狀態碼來告知舊資源因為某些內部的配置機制問題,已經永久的不可用,而且沒有任何可以跳轉的位址。404這個狀態碼被廣泛應用於當伺服器不想揭示到底為何請求被拒絕或者沒有其他適合的響應可用的情況下。出現這個錯誤的最有可能的原因是伺服器端沒有這個頁面。

這類狀態碼代表了伺服器在處理請求的過程中有錯誤或者異常狀態發生,也有可能是伺服器意識到以當前的軟硬體資源無法完成對請求的處理。除非這是乙個head 請求,否則伺服器應當包含乙個解釋當前錯誤狀態以及這個狀況是臨時的還是永久的解釋資訊實體。瀏覽器應當向使用者展示任何在當前響應中被包含的實體。

這些狀態碼適用於任何響應方法。

500 internal server error

伺服器遇到了乙個未曾預料的狀況,導致了它無法完成對請求的處理。一般來說,這個問題都會在伺服器端的源**出現錯誤時出現。

502 bad gateway

作為閘道器或者**工作的伺服器嘗試執行請求時,從上游伺服器接收到無效的響應。

504 gateway timeout

作為閘道器或者**工作的伺服器嘗試執行請求時,未能及時從上游伺服器(uri標識出的伺服器,例如http、ftp、ldap)或者輔助伺服器(例如dns)收到響應。

注意:某些**伺服器在dns查詢超時時會返回400或者500錯誤

易記的瀏覽器狀態碼

狀態碼 含義1xx 請求正被處理 2xx請求成功處理 3xx請求需要附加操作,常見的例子如重定向 4xx客戶端出錯導致請求無法被處理 5xx服務端處理出錯 表示請求已經被正常處理,這個比較常見,就不多說了。表示請求成功,但是響應的報文中不含實體主體。通常用於只需要客戶端向服務端傳送資訊,而不需要接受...

瀏覽器訪問常見狀態碼

狀態 有三位數字組成,第乙個數字定義了響應的類別,共分五種類別 響應類別 1xx接受的請求正在處理 2xx正確處理請求完畢 3xx重定向,需要附加操作才能完成請求 4xx客戶端錯誤 請求有語法錯誤或請求無法實現 5xx伺服器端錯誤 伺服器未能實現合法的請求 常見狀態碼 105 dns解析失敗 200...

瀏覽器返回的常見狀態碼

http 超文字傳輸協議,在傳輸層採用的是tcp協議。瀏覽器與伺服器建立連線時會經過tcp的三次握手,一次tcp的連線可以建立多個http請求。狀態碼為伺服器接受請求之後返回的響應資訊,瀏覽器可以根據響應資訊的狀態碼判斷請求是否成功。100 繼續 101 切換協議 2xx 表示請求成功 200 su...