爲何 CORS 須要在跨域請求前進行預校驗 (Preflight)

你們都知道瀏覽器在發起複雜跨域請求前會先發送一個 OPTIONS 請求來進行預校驗
校驗經過後纔會正式將攜帶參數的請求發送給服務器
平時談論的大可能是什麼狀況下會須要預校驗
不知道你們有沒有仔細考慮過瀏覽器爲何會這麼作？
不這麼作會不會致使什麼問題？

下面先來看看 W3C 協議 中的說法：

To protect resources against cross-origin requests that could not originate from certain user agents
before this specification existed a preflight request is made to ensure that the resource is aware of this specification.

光看這段文字可能你們仍是一頭霧水，下面讓咱們用一個例子來更加形象的描述一下這個問題
假設瀏覽器並不會發送預檢驗（Preflight）請求，而是直接發送正式請求來判斷是否容許跨域
咱們向服務器發送一個跨域的 DELETE 請求 https://www.a.com/deleteuser?id=123 來刪除一個用戶

服務端正確設置了 CORS

這種狀況下不管是否先發起預檢驗請求都沒有問題
假設不發送，服務器也能夠直接根據正式請求的來源域以及請求頭來判斷是否接受該跨域請求
未經過則返回告訴瀏覽器不容許該跨域請求
反之請求經過了跨域校驗則繼續按正常流程處理

服務端未正確設置 CORS

好比服務端使用的還是在 CORS 出現前開發的代碼
這個時候若是瀏覽器不作預檢驗，直接將真實請求發至服務器來判斷是否知足跨域條件
服務器接受到了如上的 DELETE 請求，因爲並未設置過 CORS
也就是說服務器會默認瀏覽器發來的請求都是知足同源策略的
便直接將該請求看成普通請求進行處理
在這種狀況下瀏覽器的同源策略就不攻自破了

預檢驗請求爲何能解決這個問題

你們都知道，預檢驗請求是一個不攜帶任何具體參數的 OPTIONS 請求
採用 CORS 的服務器會正確的根據請求頭來判斷是否接受該跨域請求，並返回相應的響應告知瀏覽器
未採用的服務器接受到請求也會正常處理
可是返回的響應中不會正確的包含 Access-Control-Allow-* 等響應頭
瀏覽器接收到預檢驗請求的響應後會根據響應頭來判斷是否支持跨域
只有當響應頭知足 CORS 的相關設置纔會繼續發送正式的跨域請求

---

參考資料

水平有限，若有錯誤歡迎指正

END