重定向Redirect 的常識

今天下班的時候看到了一些重定向的基礎知識，也算開了眼界。以前也經常使用301和302，但從來沒有使用過和了解過其他的3xx的狀態碼，發現原來裡面涉及的知識和解決的問題的還不少。

瀏覽器首先訪問伺服器a的url，伺服器a返回帶著location為b的url的 header 和3xx的狀態碼，瀏覽器讀取響應的3xx狀態碼，獲取到頭部的 location，然後跳轉到伺服器b的url。

需要知道的，跳轉是瀏覽器發起的。如果伺服器給乙個非瀏覽器的終端返回了3xx的狀態碼，那有可能是無法完成重定向的。

某年，有個應該用已經執行很很長時間了，php寫的api介面。一直使用的是http，經常被劫持，然後領導想替換成加密的https，但是客戶端不能發版。後來伺服器端就考慮把全站的介面從http 302到https，討論這個方案的可行性。如果知道上面的流程和知識這個方案立馬就pass了。

表示資源永久性的跳轉到新的url。

乙個比較常見的案例就是老站遷移到新站，老站直接關閉後，老站的頁面已經被搜尋引擎收錄了，這個時候使用永久重定向方案。

永久重定向兩個狀態碼

301，重定向請求通常會使用get方法，不管原請求使用的是何種方法。

308，為了補充301.重定向必須使用原請求的方法和包體訪問。

300，該請求有多種可能的響應，瀏覽器可以選擇它們其中的乙個。伺服器沒有任何標準可以遵循去代替使用者來進行選擇。

304，告訴瀏覽器，所請求的內容距離上次訪問並沒有變化。可以直接從瀏覽器快取裡獲取該資源。

後面兩種不常用。

使用比較多就是301 302 307 308

err_too_many_redirects

這個報錯挺常見的。如果訪問a頁面然後重定向訪問b，然後b又讓重定向訪問a，這樣就是迴圈重定向了。多次重定向也會報這個錯。

生產環境遇到過一次，有一次日誌上發現有err_too_many_redirects的報錯，但是在nginx的配置上沒有找到 3xx的跳轉**啊，那怎麼迴圈跳轉的。後來看到了這段配置

location /

後來發現根目錄下沒有index.html，uri不存在，然後uri/目錄也不存在，最後發起乙個內部子請求到index.html.index.html不存在，又到location，反覆重定向。最後報錯 err_too_many_redirects。