問題描述
遇到了個詭異的事情。客戶反饋他們想在線上 https 域名下，就是要訪問 http 的鏈接，但是失敗了。發出去的一直是 https 的 xhr 請求。
直接在控制檯輸入例子代碼，就能看到 network 裏發出去的鏈接的確是 https 的
var xhr = new XMLHttpRequest()
xhr.open("GET", "http://imapi.jiehun.com.cn/socket.io/1/?t=1668076877422", true)
xhr.send()
已知 XMLHttpRequest 對象控制檯輸出的的確是 native code，並不是被篡改了的，何解？
解答
參考 MDN 文檔 HTTP Strict Transport Security
HTTP-Strict-Transport-Security（通常簡稱爲 HSTS）響應標頭用來通知瀏覽器應該只通過 HTTPS 訪問該站點，並且以後使用 HTTP 訪問該站點的所有嘗試都應自動轉換爲 HTTPS。
語法
Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; preload
檢查得知客戶的網站的確是設置了這個
查閱了下
max-age=
. 設置在瀏覽器收到這個請求後的 秒的時間內凡是訪問這個域名下的請求都使用 HTTPS 請求。
includeSubDomains. 可選. 如果這個可選的參數被指定，那麼說明此規則也適用於該網站的所有子域名。
preload. 可選. 查看 預加載 HSTS 獲得詳情。不是標準的一部分。
故而這個用戶設置現在和未來的所有子域名會自動使用 HTTPS 連接長達一年。同時阻止了只能通過 HTTP 訪問的內容。且啓用了預加載服務。
preload 與預加載
谷歌維護着一個 HSTS 預加載服務。按照如下指示成功提交你的域名後，瀏覽器將會永不使用非安全的方式連接到你的域名。雖然該服務是由谷歌提供的，但所有瀏覽器都有使用這份列表的意向（或者已經在用了）。但是，這不是 HSTS 標準的一部分，也不該被當作正式的內容。
- Chrome & Chromium 的 HSTS 預加載列表： https://www.chromium.org/hsts
- Firefox 的 HSTS 預加載列表：nsSTSPreloadList.inc