93
發送XMLHttpRequest-s（即重新獲取重定向狀態代碼並自己處理它）時，是否可以防止瀏覽器跟隨重定向？防止Xmlhttprequest重定向
A
回答
84
未按the W3C standard for the XMLHttpRequest object（強調）：
如果響應是HTTP重定向：
如果由Location頭輸送的URL的起源是相同的起源 與XMLHttpRequest原點和 重定向不違反無限 循環注意事項，透明 遵循重定向，同時觀察 相同來源的請求事件規則。
他們considering它在將來的版本：
本規範不包括 正被 考慮的 未來版本的規格如下特點：
- 禁用以下重定向的屬性;
但latest規範不再提到這一點。
11
不，您在XMLHttpRequest公開的API中沒有任何地方允許您覆蓋其自動跟隨301或302的默認行爲。
如果客戶端在Windows上運行IE，那麼你可以使用WinHTTP來設置一個選項來防止這種行爲，但這是一個非常有限的解決方案。
12
您可以使用responseURL屬性獲取重定向目標或檢查響應是否最終從您接受的位置獲取。
這當然意味着無論如何都會獲取結果，但至少您可以獲取有關重定向目標的必要信息，例如在您想放棄響應時檢測條件。
19
新Fetch API支持重定向處理不同的模式：follow，error和manual，但我不能找到一種方法來查看新的URL或狀態代碼時重定向已被取消。你可以停止重定向本身，然後它看起來像一個錯誤（空響應）。如果這就是你所需要的，那麼你很好。
另外您應該知道，通過此API提出的請求不可取消
yet。
他們現在are。
至於XMLHttpRequest的，你可以HEAD服務器並檢查URL是否發生了變化：
var http = new XMLHttpRequest();
http.open('HEAD', '/the/url');
http.onreadystatechange = function() {
if (this.readyState === this.DONE) {
console.log(this.responseURL);
}
};
http.send();
你不會得到狀態代碼，但是會發現新的URL，而不從網上下載整個頁面它。
什麼是荒謬的是，當透明重定向涉及覆蓋原始請求中設置的一些HTTP頭。具體來說，如果「Accept」頭部被設置爲特定的內容類型，則Firefox在重定向後無法包含此頭文件（這使開發完全基於REST的Web服務使用此頭文件變得更加困難......嘰）。 – ruquay 2011-05-26 08:47:07
一些更多的搜索給我這個相當老的錯誤報告：https://bugzilla.mozilla.org/show_bug.cgi?id=401564 – ruquay 2011-05-26 09:22:07