參考前端
https://blog.csdn.net/charleslei/article/details/51906635json
https://blog.csdn.net/kejmln/article/details/51350777後端
開發過程當中,若是出現相似 「Origin ****** is not allowed by Access-Control-Allow-Origin.」 的錯誤,則多是因爲json數據不支持跨域致使的,應考慮使用jsonp協議跨域
beforeSend: function(XMLHttpRequest) {瀏覽器
XMLHttpRequest.setRequestHeader("sessionid", "1233333");服務器
},session
原來對於跨域,有兩種不一樣的請求類型。分別爲簡單跨域請求測試
簡單跨域請求只要後端: c.getResponse().addHeader("Access-Control-Allow-Origin", "*");jsonp
不然瀏覽器會報錯 No 'Access-Control-Allow-Origin' header is.net
和複雜跨域請求(就是header加入自定義的值,帶預檢的跨域請求)
第一次請求(預檢) 請求方法是options, method='options'
(第一個OPTIONS的請求是由Web服務器處理跨域訪問引起的)
沒有提交真正的請求(沒有提交真的數據,頭部的數據和表單的數據沒有提交
// 解決前端js跨域
若是後端設置了底下的訪問,
c.getResponse().addHeader("Access-Control-Allow-Origin", "*");
if (c.getRequest().getMethod() == "OPTIONS") { /
c.getResponse().addHeader("Access-Control-Allow-Methods", "*");
c.getResponse().addHeader("Access-Control-Allow-Headers", "*");
c.getResponse().addHeader("Access-Control-Allow-Headers", "*");
}
第二次請求
提交真的數據,頭部的數據和表單的數據有提交
===========
https://blog.csdn.net/cscrazybing/article/details/63254762
查了些資料而且測試了下, 發現OPTIONS
就是至關於在正式請求接口以前去獲取如下header, 天然就是咱們前面所設置的那些header. 若是在此次OPTIONS
請求中服務器有返回正確的header, 這時纔會執行後面真正的請求; 不然請求將會被拒絕, 並拋出錯誤