爲什麼XMLHttpRequest包含一個Origin標頭？

我想更好地理解這一點。目前我正在使用的心理模型的工作原理如下：爲什麼XMLHttpRequest包含一個Origin標頭？

在foo.com上託管的JS希望訪問在bar.com託管的資源。這不是瀏覽器喜歡公開他們的用戶的東西，除非它可以顯示bar.com歡迎這個請求。
因此，foo.com JS將請求分爲兩部分。首先，我們通過XMLHttpRequest對象發送適當類型的無數據請求（GET，POST等）。 bar.com上的服務器返回通常會對基本上任何請求（包括或不包括Access-Control-Allow-Origin標頭）的請求作出響應。（編輯：這是一個誤解 - 請參閱下面的apsillers的優秀評論）
如果瀏覽器確實得到這樣的標題，它會掃描它的Origin（本例中爲foo.com）。如果存在，它將繼續發送請求發送的實際請求。如果不是，它拒絕。（編輯：這也不是很正確）

如果這個模型是正確的，我很困惑，爲什麼瀏覽器發出一個Origin頭與此初步請求。客戶端不會發生檢查嗎？發送這個頭文件實現了什麼？

來源

2012-11-19 Greg Pallis

實際上，一個無數據的預檢請求僅與「非簡單的」 HTTP動詞發生* （例如，PUT，DELETE等），並且預檢請求使用OPTIONS動詞。 – apsillers

@apsillers - 其他動詞*或*使用自定義標題。我不知道爲什麼;我認爲這個補丁有一些安全漏洞。 – Malvolio

@Malvolio好的，謝謝，我忘了客戶的標題。非簡單動詞對我更有意義（因爲我們不希望DELETE觸及服務器，除非服務器說它是受歡迎的）。我也對自定義標題預檢要求感到困惑。 – apsillers

這是如何CORS works。這基本上是一個握手，說是的，歡迎你與我交談。除非與第三方聯繫，否則無法確定是否有可能。

以下是的MDN article的Preflighted_requests部的局部部分：

不同於簡單的請求（上面討論的），「預檢」請求第一發送一個HTTP OPTIONS請求報頭添加到資源上的其他的域名，以確定發送的實際請求是否安全到。跨站點請求以這種方式進行預檢，因爲它們可能會對用戶數據產生影響。特別是，請求預衝如果：

它使用GET或POST以外的方法。另外，如果POST被用於發送具有除 application/x-www-form-urlencoded，multipart/form-data或text/plain之外的內容類型的請求數據，例如。如果POST請求使用 application/xml或text/xml將XML有效載荷發送到服務器，則會預先顯示該請求。它設置自定義首部中的請求（例如，請求使用的報頭，如 X-PINGOTHER）比* GET和POST其他

來源

2012-11-19 18:37:54 epascarello

這是一個非常有用的鏈接 - 謝謝！ –

爲什麼XMLHttpRequest包含一個Origin標頭？

回答

相關問題