CORS跨域資源共享是先後端跨域十分經常使用的一種方案,主要依賴Access-Control-Allow(ACA)系列header來實現一種協商性的跨域交互。javascript
其中的具體流程大體能夠分爲如下幾步:html
一、前端從webview上發出ajax請求
二、瀏覽器監測到ajax跨域,添加origin頭部,標明請求來源
三、後端接收到請求後,根據正常業務邏輯包裝業務返回
四、在業務返回的response上添加ACA系列頭部,如\前端
'Access-Control-Allow-Origin' '*';
'Access-Control-Allow-Credentials' "true";
'Access-Control-Allow-Headers' 'X-Requested-With';
複製代碼
等等
五、瀏覽器接收到返回後判斷ACA-Origin和以前加上的origin頭部是否相符,相符的話進入6,不然進入第7步
六、返回完整的response內容到ajax的success中,ajax結束
七、拋出Error對象到給瀏覽器處理,置空response的返回給ajax處理java
若是畫一個來理解的話,大體以下nginx
以上就是「簡單跨域」的基本模型,複雜跨域還存在一層瀏覽器發起預檢options請求,而後服務端先校驗預檢請求,經過以後再走正常請求的流程,更詳盡的內容你們能夠去看一下阮一峯老師寫的《跨域資源共享 CORS 詳解》,裏面介紹的很詳盡,在這裏也不在細說了。下面說說本文的另外一個重點--常見理解誤區web
看下這個問題ajax
Q: 跨域失敗的時候,後端接口返回的內容是什麼樣的?後端
當咱們不少時候都在思考怎麼跨域的時候,不知道你們有沒有想過這個問題?跨域失敗很天然的給人的想法就是拿不到數據,那確定就是後端沒有返回啊。然而不少咱們理所固然的卻不併是理所固然的那個樣子。 事實是,跨域
A: 簡單的跨域請求,跨域失敗時對於後端是沒有影響的,跨域該怎麼返回怎麼返回,返回的數據和你跨域成功的時候基本是一致的,包含業務邏輯的除外,由於可能涉及到登陸信息傳遞的問題瀏覽器
來個例子 咱們在一個頁面上發送了一個xxx/ 的簡單跨域請求,接口端沒作cors處理,這時咱們在瀏覽器會看到
什麼返回都沒有,response返回體是空的,控制檯報錯啦,事實上呢?咱們用charles抓包看到的實際狀況是 看到沒?服務端返回的是正常數據啊。這個時候咱們回頭看看上面咱們寫的那個cors模型流程,服務端接口所作的工做和非跨域請求惟一的區別只是多加了那麼幾個ACA的頭部,你以爲這幾個ACA的頭部直接就把數據搞沒了?Naive。因此接口返回的返回體徹底沒變。
所以說對於簡單跨域請求來講,服務端主要負責配置處理一些ACA的header就能夠了。回顧一下跨域的概念,你會發現跨域自己只是瀏覽器上因爲同源策略才存在的一種安全保障行爲,服務端一個接口可能供給瀏覽器中的接口調用,也能夠同時給其餘服務使用。一個接口數據返回來了,瀏覽器判斷是否是跨域你本身去處理就能夠了。
這個問題說實話最開始的時候,個人反應也是錯的,後面仔細想了想才獲得這個答案,或許這只是和我同樣小白的誤區,但願對你們有所幫助吧。
又打臉了,emmm。。。你們多多指正吧,臨時改了下,週末找個時間,徹底從新寫一下吧
~全篇完~
前面還寫了一個nginx跨域相關的《前端也要懂的Nginx反向代理跨域》,你們有興趣歡迎來踩,若有問題歡迎指出~
~真·全篇完~
emmm最近咱們又要招人了,螞蟻金服-芝麻信用招前端P6/7,共5個,5個呢!5個!機會可貴!加油啊!你能夠的!,大廠你懂的,獎金分你一半啊,感興趣的快來試試吧,有興趣微信聊聊的加我哈heiohiio,簡歷直接丟我郵箱也能夠啊~heioray@sina.com