徹底搞懂 HTTP 3XX 重定向狀態(tài)碼和瀏覽器重定向

時(shí)間：2023-02-09 07:36:01 | 來源：建站知識(shí)

時(shí)間：2023-02-09 07:36:01 來源：建站知識(shí)

最近好好研究了一下 HTTP 的 3XX 狀態(tài)碼，發(fā)現(xiàn)這里面涉及到的知識(shí)點(diǎn)還挺多的，很多在我們?nèi)粘ｉ_發(fā)過程中也會(huì)用到，于是就想通過這篇文章來和大家聊一聊它們的含義以及應(yīng)用場(chǎng)景。

3XX 狀態(tài)碼是關(guān)于重定向的，常見的狀態(tài)碼有：301，302，303，304，307 和 308。這些狀態(tài)碼大致可以分為三類，其中包括：

• 永久重定向：301，308
• 臨時(shí)重定向：302，303， 307
• 其他重定向：304

這篇文章主要分析永久重定向和臨時(shí)重定向相關(guān)的狀態(tài)碼，至于其他重定向就不在這里細(xì)講了。

PS: 正文里提到的 3XX 響應(yīng)只包含永久重定向和臨時(shí)重定向所對(duì)應(yīng)的 HTTP 狀態(tài)碼，不包括其他重定向。

開始

我們既需要明白服務(wù)器發(fā)送的各種重定向狀態(tài)碼是什么含義，還需要搞清楚瀏覽器收到這些重定向狀態(tài)碼之后會(huì)怎么做。因此本文會(huì)從服務(wù)器和瀏覽器兩個(gè)部分進(jìn)行講解。

服務(wù)器

永久重定向

永久重定向，是指用戶請(qǐng)求的資源地址已經(jīng)廢棄了，現(xiàn)在需要使用新地址來訪問，并通過響應(yīng) Header 的 Location 字段將這個(gè)新的地址告知給用戶。

就好比胡同口有一家我們常去的飯店，但是由于舊城改造這家店搬遷到了另一個(gè)地方。有一天我們準(zhǔn)備去這家店吃飯，發(fā)現(xiàn)門口張貼告示：此店已遷移到 XXX，并附上了詳細(xì)的新地址。也就是說，之后如果我還想去這家店吃飯，只能去新的地址。

301 Moved Permanently

表示請(qǐng)求資源已經(jīng)被移動(dòng)到了由 Location 頭部指定的 URI 上，是固定的不會(huì)再改變。在用新 URL 發(fā)起請(qǐng)求時(shí)，對(duì)于 GET 請(qǐng)求保持不變，但是對(duì)于 POST 請(qǐng)求，盡管標(biāo)準(zhǔn)要求瀏覽器在收到該響應(yīng)時(shí)不應(yīng)該修改 HTTP Method 和 Request Body，但是大多數(shù)瀏覽器沒有遵守這個(gè)標(biāo)準(zhǔn)，會(huì)把原本為 POST 的請(qǐng)求重定向到 GET 請(qǐng)求上。

我們拿 Chrome 瀏覽器測(cè)試了一下，結(jié)果如下：







從上面的截圖中可以看出，瀏覽器在收到 302 響應(yīng)之后，從 Location 里面獲取到了 /pets 這個(gè)新的地址，并發(fā)起了新的請(qǐng)求。但是，這個(gè)新的請(qǐng)求使用的是 GET 方法而非我們?cè)瓉淼?POST 方法，Request Body 也丟失了。

應(yīng)用場(chǎng)景：

比如某個(gè)應(yīng)用進(jìn)行了整站重構(gòu)，重構(gòu)之后 URL 發(fā)生了改變，這時(shí)候可以考慮將老 URL 重定向到新 URL。

308 Permanent Redirect

跟 301 一樣，唯一的區(qū)別就是瀏覽器不會(huì)改變請(qǐng)求的 HTTP Method 和 Request Body。

我們又繼續(xù)拿 Chrome 測(cè)試了一下，結(jié)果如下：







可以看出，使用 308 之后，請(qǐng)求的 Method 和 Request Body 都沒有發(fā)生改變，還是跟原來一樣。

臨時(shí)重定向

由于某些原因，導(dǎo)致用戶請(qǐng)求的資源地址臨時(shí)不可用，但其他某個(gè)地址是可訪問的，于是就通過響應(yīng) Header 的 Location 字段將這個(gè)臨時(shí)地址告知給用戶。

就好比我們?nèi)ヒ患绎埖瓿燥垼介T口發(fā)現(xiàn)老板張貼告示：家里臨時(shí)有事，請(qǐng)去附近另一個(gè)分店用餐，并附上了分店的詳細(xì)地址。這樣，我們就可以先臨時(shí)去這家分店用餐，等之后老板回來了，我們又可以在原來這家店繼續(xù)用餐。

302 Found

在收到 302 響應(yīng)之后，瀏覽器會(huì)發(fā)起新的請(qǐng)求，盡管標(biāo)準(zhǔn)要求瀏覽器在收到該響應(yīng)時(shí)不應(yīng)該修改 HTTP Method 和 Request Body，但是大多數(shù)瀏覽器都沒有遵守這個(gè)標(biāo)準(zhǔn)。大多數(shù)瀏覽器會(huì)將 302 請(qǐng)求視為 303 請(qǐng)求，也就是說 302 和 303 幾乎是一樣的。

應(yīng)用場(chǎng)景舉例：

通常圖片資源會(huì)放到類似 S3 這樣的靜態(tài)資源服務(wù)器，出于對(duì)隱私和安全的考慮，我們有時(shí)不能直接通過靜態(tài)資源服務(wù)器的 URL 訪問到這個(gè)圖片，而是需要后端通過身份憑證去 S3 簽發(fā)一個(gè)臨時(shí)地址（這個(gè)地址用一次就失效了，下一次需要重新簽發(fā)），然后我們才能通過這個(gè)臨時(shí)地址訪問到真正的圖片資源。

對(duì)于這個(gè)場(chǎng)景，302/303 就非常有用了。比如，前端可以使用一個(gè)固定的 URL 來訪問圖片資源 (<img src="/image/foo.jpg")，這個(gè) URL 由后端提供，后端在生成完臨時(shí)地址之后，可以直接通過 302/303 重定向到這個(gè)新的地址，接下來瀏覽器會(huì)再次發(fā)起請(qǐng)求，獲取新地址指向的這個(gè)圖片資源。

303 See Other

瀏覽器在收到 303 響應(yīng)之后，除 GET 方法保持不變之外，其他所有方法都會(huì)被改為 GET 方法，同時(shí) Request Body 也會(huì)丟失。一般用于將 POST 方法重定向到 GET 方法。

應(yīng)用場(chǎng)景舉例：

假設(shè)我們有一個(gè)非常原始的表單，這個(gè)表單是通過在 HTML 上設(shè)置 action 和 method 來提交的。在表單提交之后，瀏覽器會(huì)自動(dòng)跳轉(zhuǎn)到 action 所在的地址，并使用 method 所指定的方法向服務(wù)器發(fā)起請(qǐng)求，在收到服務(wù)器的303 響應(yīng)之后，又需要跳轉(zhuǎn)回原來這個(gè)頁面。

<form action="http://example.com/api/form" method="POST"> <input type="text" name="name" placeholder="name"> <input type="email" name="email" placeholder="email"> <input type="submit" value="Submit"></form>這里就會(huì)出現(xiàn)一個(gè)問題，假設(shè)我們頁面的 URL 是 http://example.com ，我們只能通過 GET 方法請(qǐng)求這個(gè)頁面。而提交表單所使用的 URL 是 http://example.com/api/form ，我們只能通過 POST 方法來調(diào)用這個(gè)接口。在使用 POST 方法提交表單之后，如果我們想返回原來的頁面，只能使用 GET 方法發(fā)起請(qǐng)求，因此我們需要使用 303 狀態(tài)碼，將原來的 POST 方法改成 GET。

307 Temporary Redirect

307 和 303 一樣，唯一的區(qū)別就是瀏覽器不會(huì)改變請(qǐng)求的 HTTP Method 和 Request Body。對(duì)于 POST/PUT 等非 GET 請(qǐng)求很有用。

應(yīng)用場(chǎng)景：

在上傳文件時(shí)，我們通常會(huì)調(diào)用后端提供的某個(gè) API (/upload)，但由于上傳會(huì)占用大量的服務(wù)器資源和帶寬，這個(gè) API 一般不會(huì)處理真正的上傳，而是通過另一個(gè)專門的上傳服務(wù)來完成。這意味著我們需要調(diào)用兩次 API 才能完成上傳功能，一次是調(diào)用后端接口獲取真正的上傳地址，另一次是攜帶 Request Body 請(qǐng)求這個(gè)上傳地址，完成真正的上傳。

如果讓兩個(gè) API 的請(qǐng)求參數(shù)和方法保持一致，那么對(duì)于前端來說，只需要發(fā)起一次請(qǐng)求即可，后端在生成完上傳地址后，通過 307 重定向到這個(gè)地址，然后瀏覽器會(huì)使用之前的 Request Body 和 HTTP Method 請(qǐng)求這個(gè)新的地址，這樣就完成了上傳。

注意，如果使用 302 會(huì)導(dǎo)致上傳失敗，原因是 302 會(huì)將 PUT 改為 GET 請(qǐng)求，同時(shí) Request Body 也會(huì)丟失。

其他常見的重定向場(chǎng)景

域名別稱

1. 擴(kuò)大站點(diǎn)的用戶覆蓋面。比如訪問 http://www.google.com 會(huì)被重定向到 http://google.com
2. 遷移到另一個(gè)域名。
3. 強(qiáng)制使用 HTTPS 協(xié)議。比如訪問 http://baidu.com 會(huì)被重定向到 https://baidu.com

保持鏈接有效

當(dāng)重構(gòu)網(wǎng)站時(shí)，可能會(huì)讓資源的 URL 發(fā)生改變。但我們并不想因此使舊鏈接失效，因?yàn)檫@些鏈接不僅可以給你帶來寶貴的用戶，還能夠幫助優(yōu)化 SEO，因此需要建立從舊鏈接到新鏈接的重定向映射。

瀏覽器

我們已經(jīng)了解了各種關(guān)于重定向的 HTTP 狀態(tài)碼，那么瀏覽器收到這些狀態(tài)碼之后會(huì)做些什么呢？當(dāng)瀏覽器收到 3XX 響應(yīng)之后，是否會(huì)將地址欄的 URL 修改為響應(yīng) Header 中 Location 字段所指定的 URL，并跳轉(zhuǎn)到這個(gè)新的 URL 呢？ 請(qǐng)接著往下看。

收到 3XX 響應(yīng)后，瀏覽器是否會(huì)改變地址欄并跳轉(zhuǎn)？

瀏覽器是否會(huì)改變地址欄并跳轉(zhuǎn), 其實(shí)取決于請(qǐng)求的 URL 是否會(huì)讓文檔加載/重新加載。這里所指的文檔加載/重新加載，既包括當(dāng)我們通過瀏覽器地址欄訪問某個(gè) URL、刷新頁面所導(dǎo)致的文檔加載，也包括我們通過 window.location 讓文檔用新的 URL 加載。只有在這些情況下，如果我們請(qǐng)求的 URL 返回了 3XX 響應(yīng)，瀏覽器才會(huì)讀取響應(yīng) Header 里面的 Location 字段，并將瀏覽器的地址欄修改為這個(gè)字段所指定的 URL，然后跳轉(zhuǎn)到這個(gè) URL。

一般來說文檔加載/重新加載都會(huì)產(chǎn)生一個(gè) Document 類型的請(qǐng)求，如下所示：

PS: React Router 這樣的路由跳轉(zhuǎn)，不會(huì)讓文檔重新加載 ( 因?yàn)槭褂玫氖?History API )

但是，如果是通過 fetch/XMLHttpRequest 調(diào)用所獲取到的 3XX 響應(yīng)，瀏覽器是不會(huì)改變當(dāng)前地址欄的 URL 并跳轉(zhuǎn)的。試想，我們?cè)谠L問圖片時(shí)，經(jīng)常會(huì)得到很多 302 響應(yīng)，如果瀏覽器要跳轉(zhuǎn) URL，豈不是會(huì)導(dǎo)致整個(gè)瀏覽器崩潰。

window.location + 3XX 響應(yīng)

window.location 能夠讓文檔用新的 URL 加載，默認(rèn)會(huì)將新的 URL push 到瀏覽器 history 的路由堆棧里面，如果你想使用 replace 的方式，可以調(diào)用 window.location.replace() 方法:

window.location = "http://www.mozilla.org";function reloadPageWithHash() { var initialPage = window.location.pathname; window.location.replace('http://example.com/#' + initialPage);}應(yīng)用場(chǎng)景：

在使用 OAuth2 鑒權(quán)時(shí)（比如微信登錄），可以通過 window.location 重定向到自己服務(wù)器的授權(quán)地址（支持多個(gè)平臺(tái)登錄時(shí)，可以由后端統(tǒng)一處理），然后服務(wù)器會(huì)生成一個(gè)三方授權(quán)點(diǎn)的地址，并通過 302 響應(yīng)告知給瀏覽器，瀏覽器在收到響應(yīng)之后會(huì)跳轉(zhuǎn)到這個(gè)三方授權(quán)點(diǎn)的 URL（微信登錄頁），完成授權(quán)之后，三方授權(quán)頁面會(huì)通過 window.location 再重定向回我們自己的頁面。

通過 window.location 再配合 302 響應(yīng)，我們可以快速將用戶導(dǎo)向三方授權(quán)點(diǎn)，不需要加載任何 JS，非?？焖俜奖恪?br>






參考：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Redirections