在全站啓用HTTPS的過程中，遇到一個坑，在此做下記錄。在全站支持HTTPS以後，用戶可能還會使用http訪問，所以很多建議使用301 Moved Permanently+HSTS（ Strict Transport Security Policy）的方式要求用戶跳轉到HTTPS後再訪問。
然而，對於有POST請求的域名是不適合用301 Moved Permanently的，關於post請求重定向用戶確認的問題，實際上瀏覽器都沒有實現；而且post請求的重定向應該發起post請求，這裏瀏覽器也並不一定遵守，所以說HTTP規範的實現並未嚴格按照HTTP規範的語義。如下圖所示。
所以這種情況，一個POST請求經過301後可能就變爲GET請求。而很多服務端是對METHOD有嚴格限制的，萬一限制只接受POST請求，對GET請求就會響應405錯誤，悲劇就產生了。
那麼POST請求應該如何解決跳轉問題呢？
HTTP/1.1 301 Moved Permanently： 301狀態碼在HTTP 1.0和HTTP 1.1規範中均代表永久重定向，對於資源請求，原來的url和響應頭中location的url而言，資源應該對應location中的url。對於post請求的重定向，還是需要用戶確認之後才能重定向，並且應該以post方法發出重定向請求。
關於post請求重定向用戶確認的問題，實際上瀏覽器都沒有實現；而且post請求的重定向應該發起post請求，這裏瀏覽器也並不一定遵守，所以說HTTP規範的實現並未嚴格按照HTTP規範的語義。
在301中資源對應的路徑修改爲location的url，在SEO中並未出現問題，但是在302中就出現了302劫持問題，請往下看。
HTTP/1.1 302 Found ：在HTTP1.0規範中，302表示臨時重定向，location中的地址不應該被認爲是資源路徑，在後續的請求中應該繼續使用原地址。
規範：原請求是post，則不能自動進行重定向；原請求是get，可以自動重定向；
實現：瀏覽器和服務器的實現並沒有嚴格遵守HTTP中302的規範，服務器不加遵守的返回302，瀏覽器即便原請求是post也會自動重定向，導致規範和實現出現了二義性，由此衍生了一些問題，譬如302劫持，因此在HTTP 1.1中將302的規範細化成了303和307，希望以此來消除二義性。
補充：302劫持——A站通過重定向到B站的資源xxoo，A站實際上什麼都沒做但是有一個比較友好的域名，web資源xxoo存在B站並由B站提供，但是B站的域名不那麼友好，因此對搜索引擎而言，可能會保存A站的地址對應xxoo資源而不是B站，這就意味着B站出了資源版權、帶寬、服務器的錢，但是用戶通過搜索引擎搜索xxoo資源的時候出來的是A站，A站什麼都沒做卻被索搜引擎廣而告之用戶，B站做了一切卻不被用戶知道，價值被A站竊取了。
作爲HTTP1.1的標準,以前叫做Moved Temporarily ,現在叫Found. 現在使用只是爲了兼容性的處理,包括PHP的默認Location重定向用的也是302.
但是HTTP 1.1 有303 和307作爲詳細的補充,其實是對302的細化
HTTP/1.1 303 See Other：對於POST請求，它表示請求已經被處理，客戶端可以接着使用GET方法去請求Location裏的URI。
HTTP/1.1 307 Temporary Redirect：對於POST請求，表示請求還沒有被處理，客戶端應該向Location裏的URI重新發起POST請求。
所以，對待POST請求，我們可以使用307跳轉的方式來解決。
---------------------
作者：皖南笑笑生
來源：CSDN
原文：https://blog.csdn.net/zhuyiquan/article/details/78712332
版權聲明：本文爲博主原創文章，轉載請附上博文鏈接！