Chrome遇到http 307錯誤
這幾天在使用dnspod的域名顯性轉發功能，發現有一個域名在Chrome下怎麼也無法正確轉向，清理了Chrome緩存，刷新本地dns，修改域名dns均無效，但是在其他瀏覽器可正常轉向，咨詢了騰訊雲客服，也表示正常轉向，很明顯就是Chrome問題，f12查看network，發現有個307錯誤。查找資料後問題解決。
現代瀏覽器和服務器都開始支持 HSTS(HTTP Strict Transport Security) 功能，即自動將不安全的 HTTP 請求使用 307 Internal Redirect 跳轉到 HTTPS 請求。這是由Chrome內部HSTS緩存導致的。Chrome 會自動記住每個域的 HSTS 設置，也就是說HSTS只要在理論上的第一次暴露後，後來就不經網頁服務器返回，瀏覽器會查詢本地數據，直接偽造 HSTS 307 跳轉到安全的 HTTPS，以此來加強網絡訪問的安全性。
這的確是個很先進的功能，但對開發人員的調試環境就帶來了麻煩，一旦網頁服務器設置了 HSTS，且在理論上的第一次無意或有意訪問過，這就被瀏覽器緩存住了。此後，瀏覽器自行決定將不會再訪問該域的 HTTP了，哪怕服務端已經修改了相關配置。
解決方法：在Chrome打開 chrome://net-internals/#hsts ，在Query HSTS/PKP domain段可以查詢您訪問的域名是否有HSTS緩存，存在的話，在Delete domain security policies段中刪除即可。
關於301，302，303，307的介紹
在HTTP/1.1中，新增了303 See Other、307 Temporary Redirect這兩個狀態碼，這兩個狀態碼和301、302狀態碼有什麽區別呢？
1. 對於301、302的location中包含的重定向url，如果請求method不是GET或者HEAD，那麽瀏覽器是禁止自動重定向的，除非得到用戶的確認，因為POST、PUT等請求是非冥等的（也就是再次請求時服務器的資源可能已經發生了變化）。
2. 雖然rfc明確了上述的規定，但是很多的瀏覽器不遵守這條規定，無論原來的請求方法是什麽都會自動用GET方法重定向到location指定的url。就是說現存的很多瀏覽器在遇到POST請求返回301、302狀態碼的時候自動用GET請求location中的url，無需用戶確認。
3. HTTP 1.1中新增了303、307狀態碼，用來明確服務器期待客戶端進行何種反應。
4. 303狀態碼其實就是上面301、302狀態碼的」不合法」動作，指示客戶端可以自動用GET方法重定向請求location中的url，無需用戶確認。也就是把前面301、302狀態碼的處理動作」合法化」了。
5. 307狀態碼就是301、302原本需要遵守的規定，除GET、HEAD方法外，其他的請求方法必須等客戶確認才能跳轉。
6. 303、307其實就是把原來301、302不」合法」的處理動作給」合法化」，因為發現大家都不太遵守，所以幹脆就增加一條規定。
HSTS介紹
HSTS（HTTP Strict Transport Security）國際互聯網工程組織IETF正在推行一種新的Web安全協議
HSTS的作用是強製客戶端（如瀏覽器）使用HTTPS與服務器創建連接。
國際互聯網工程組織IETE正在推行一種新的Web安全協議HTTP Strict Transport Security（HSTS），采用HSTS協議的網站將保證瀏覽器始終連接到該網站的HTTPS加密版本，不需要用戶手動在URL地址欄中輸入加密地址。該協議將幫助網站采用全局加密，用戶看到的就是該網站的安全版本。HSTS的作用是強製客戶端（如瀏覽器）使用HTTPS與服務器創建連接。服務器開啟HSTS的方法是，當客戶端通過HTTPS發出請求時，在服務器返回的超文本傳輸協議響應頭中包含Strict-Transport-Security字段。非加密傳輸時設置的HSTS字段無效。比如，https://xxx 的響應頭含有Strict-Transport-Security: max-age=31536000; includeSubDomains。這意味著兩點：在接下來的一年（即31536000秒）中，瀏覽器只要向xxx或其子域名發送HTTP請求時，必須采用HTTPS來發起連接。比如，用戶點擊超鏈接或在地址欄輸入 http://xxx/ ，瀏覽器應當自動將 http 轉寫成 https，然後直接向 https://xxx/ 發送請求。
在接下來的一年中，如果 xxx 服務器發送的TLS證書無效，用戶不能忽略瀏覽器警告繼續訪問網站。HSTS可以用來抵禦SSL剝離攻擊。SSL剝離攻擊是中間人攻擊的一種，由Moxie Marlinspike於2009年發明。他在當年的黑帽大會上發表的題為「New Tricks For Defeating SSL In Practice」的演講中將這種攻擊方式公開。SSL剝離的實施方法是阻止瀏覽器與服務器創建HTTPS連接。它的前提是用戶很少直接在地址欄輸入https://，用戶總是通過點擊鏈接或3xx重定向，從HTTP頁面進入HTTPS頁面。所以攻擊者可以在用戶訪問HTTP頁面時替換所有https://開頭的鏈接為http://，達到阻止HTTPS的目的。
HSTS可以很大程度上解決SSL剝離攻擊，因為只要瀏覽器曾經與服務器創建過一次安全連接，之後瀏覽器會強製使用HTTPS，即使鏈接被換成了HTTP。
另外，如果中間人使用自己的自簽名證書來進行攻擊，瀏覽器會給出警告，但是許多用戶會忽略警告。HSTS解決了這一問題，一旦服務器發送了HSTS字段，用戶將不再允許忽略警告。
原文地址：https://www.cnblogs.com/Don/p/12192420.html
顯性轉發：https://docs.dnspod.cn/dns/5f2d4664e8320f1a740d9ced/