最近在專案中因前後端部署不同地方，前端在請求後端api時發生了跨域請求，我們採用cors(跨域資源共享)來解決跨域請求，這需要前後端的配合來完成。在這一過程中，後端支援了cors跨域請求後，前端的請求配置可能會調起cors的preflight請求，也就是我們所說的預檢請求。對cors不太熟悉的可能會很容易忽視掉這個問題。下面就來說說cors的preflight請求。cors的基本用法不在本文討論中，可以參考阮老師的跨站資源共享cors詳解。
preflight請求，就是在發生cors請求時，瀏覽器檢測到跨域請求，會自動發出乙個options請求來檢測本次請求是否被伺服器接受。乙個options請求一般會攜帶下面兩個與cors相關的頭：
伺服器通過cors跨域請求後，下面瀏覽器就會發生正式的資料請求。整個請求過程其實是發生了兩次請求：乙個預檢請求，通過後的實際資料請求。這些都可以在瀏覽器網路請求中看到。可以參考下圖：
需要注意的是：
1、在上面的兩次請求中，預檢請求只是乙個檢查的過程，它不會攜帶任何請求的引數；預檢通過後的請求才會真正的攜帶請求引數與伺服器進行資料通訊。
2、若伺服器對預檢請求沒有任何響應，那麼瀏覽器不知道伺服器是否支援cors而不會傳送後續的實際請求；或者伺服器不支援當前的origin跨域訪問也不會傳送後續請求。上面的預檢請求並不是cors請求的必須的請求過程，在一定的條件下並不需要發生預檢請求。那麼發生預檢請求的條件是什麼呢？根據http訪問控制(cors)介紹，其實發生預檢請求的條件：是否是簡單請求。簡單請求則直接傳送具體的請求而不會產生預檢請求。具體來說如下：
滿足下面的所有條件就不會產生預檢請求，也就是該請求是簡單請求：
所以，在專案中是否會觸發cors的預檢請求要做到心中有數。
我們拿乙個實際發生預檢請求的例子來說明整個過程。考慮下面的乙個例子：
通過上圖可以看到請求實際產生了2次與服務互動的過程，最後一次會將請求引數傳給伺服器。這樣乙個cors請求過程就完成了。
需要注意的乙個有關cors的點：
對於附帶身份憑證的請求(即伺服器設定access-control-allow-credentials: true)，伺服器不得設定 access-control-allow-origin 的值為「*」。否則請求將會失敗。個人理解是cookie還是遵循同源策略的，即使因為這個請求是跨域請求，所以每個origin的cookie是不能被其他origin獲取到的，也就是不允許access-control-allow-origin 的值為「*」。
1、跨域資源共享 cors 詳解
2、http訪問控制（cors）
最近在專案中因前後端部署不同地方，前端在請求後端api時發生了跨域請求，我們採用cors(跨域資源共享)來解決跨域請求，這需要前後端的配合來完成。在這一過程中，後端支援了cors跨域請求後，前端的請求配置可能會調起cors的preflight請求，也就是我們所說的預檢請求。對cors不太熟悉的可能會很容易忽視掉這個問題。下面就來說說cors的preflight請求。cors的基本用法不在本文討論中，可以參考阮老師的跨站資源共享cors詳解。
preflight請求，就是在發生cors請求時，瀏覽器檢測到跨域請求，會自動發出乙個options請求來檢測本次請求是否被伺服器接受。乙個options請求一般會攜帶下面兩個與cors相關的頭：
伺服器通過cors跨域請求後，下面瀏覽器就會發生正式的資料請求。整個請求過程其實是發生了兩次請求：乙個預檢請求，通過後的實際資料請求。這些都可以在瀏覽器網路請求中看到。可以參考下圖：
需要注意的是：
1、在上面的兩次請求中，預檢請求只是乙個檢查的過程，它不會攜帶任何請求的引數；預檢通過後的請求才會真正的攜帶請求引數與伺服器進行資料通訊。
2、若伺服器對預檢請求沒有任何響應，那麼瀏覽器不知道伺服器是否支援cors而不會傳送後續的實際請求；或者伺服器不支援當前的origin跨域訪問也不會傳送後續請求。上面的預檢請求並不是cors請求的必須的請求過程，在一定的條件下並不需要發生預檢請求。那麼發生預檢請求的條件是什麼呢？根據http訪問控制(cors)介紹，其實發生預檢請求的條件：是否是簡單請求。簡單請求則直接傳送具體的請求而不會產生預檢請求。具體來說如下：
滿足下面的所有條件就不會產生預檢請求，也就是該請求是簡單請求：
所以，在專案中是否會觸發cors的預檢請求要做到心中有數。
我們拿乙個實際發生預檢請求的例子來說明整個過程。考慮下面的乙個例子：
通過上圖可以看到請求實際產生了2次與服務互動的過程，最後一次會將請求引數傳給伺服器。這樣乙個cors請求過程就完成了。
需要注意的乙個有關cors的點：
對於附帶身份憑證的請求(即伺服器設定access-control-allow-credentials: true)，伺服器不得設定 access-control-allow-origin 的值為「*」。否則請求將會失敗。個人理解是cookie還是遵循同源策略的，即使因為這個請求是跨域請求，所以每個origin的cookie是不能被其他origin獲取到的，也就是不允許access-control-allow-origin 的值為「*」。
1、跨域資源共享 cors 詳解
2、http訪問控制（cors）
關於CORS預檢
最近公司要求去掉所有請求的 於是發現了乙個很奇妙的問題，請求乙個服務時，使用 get 返回的是正確的，但是使用openlayers.request.get則會返回500，於是開啟控制台看看兩個請求之間的區別 心思縝密的我一下子就發現了問題 openlayers.request.get發出的竟然是op...
CORS 簡談options預請求
你是否是在network檢視介面響應值時偶然發現了乙個介面竟然發起了兩次請求，你抱著優化 的心理，刨根問底的態度，點開了第乙個請求發現並沒有返回值，對比第二個請求發現第乙個的request method 竟然是options，why？出現options請求的場景是發生在前後端兩方存在跨域請求的情況，...
CORS 為什麼要區分 簡單請求 和 預檢請求 ？
cors cross origin resource sharing 跨源資源共享 一般俗稱 跨域請求 想必大家都已經有基本的了解。如果你還不了解的話，可以閱讀mdn 上的介紹 這裡就不贅述了。不過在學習cors時，有些朋友會有疑惑，為什麼cors要把請求分成兩類 簡單請求和預檢請求 preflig...