今天下班的時候看到了一些重定向的基礎知識，也算開了眼界。以前也經常使用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.重定向必須使用原請求的方法和包體訪問。

臨時重定向

表示資源只是臨時跳轉到新的URL
臨時重定向一共有五個狀態碼，常用也就相對應的兩個302和307.
302，重定向請求通常會使用GET方法，不管原請求使用的是何種方法。
303，並不表示資源變更，只是表示用新的URL的響應代替原請求。不管原請求使用的是何種方法。基本跟302一致，所以市面很少用303，都是使用302.

300，該請求有多種可能的響應，瀏覽器可以選擇它們其中的一個。伺服器沒有任何標準可以遵循去代替使用者來進行選擇。
304，告訴瀏覽器，所請求的內容距離上次訪問並沒有變化。 可以直接從瀏覽器快取裡獲取該資源。
後面兩種不常用。

使用比較多就是301 302 307 308

迴圈重定向的問題

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

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

    location / {
        try_files $uri $uri/ /index.html$is_args$args;
    }

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