在文章「從微信小程序訪問APIM出現200空響應的問題中發現CORS的屬性[terminate-unmatched-request]功能」中分析了CORS返回空200的問題後,進一步對APIM的CORS策略進行驗證,深刻學習<CORS 跨域資源共享>。html
首先,咱們已經學習到CORS須要瀏覽器和服務器同時支持。目前,全部瀏覽器都支持該功能,整個CORS通訊過程,都是瀏覽器自動完成,不須要用戶參與。而服務端則不一樣,它是實現CORS通訊的關鍵。只要服務器實現了CORS接口,就能夠跨源通訊。本文中服務端就是Azure APIM (https://portal.azure.cn/#blade/HubsExtension/BrowseResource/resourceType/Microsoft.ApiManagement%2Fservice)。json
在APIM中,是經過配置策略(Policy)來實現CORS設置的。在APIM門戶中由多種級別能夠開啓CORS,能夠根據API的使用狀況靈活配置不一樣的跨域策略(cors policy)。小程序
1) 產品級別(Products Policies):做用範圍爲產品下的所有API微信小程序
2) All APIs 級別 (Inbound processing):做用範圍爲當前APIM中的全部API,因此在查看策略時,必定要注意是否有全局策略api
3) All operstions 級別(Inbound processing):做用範圍爲當前一個API下面的全部操做,如GET, POST, PUT.... 跨域
4) One Operation級別 (最原子級,隻影響一個操做): 有效範圍僅對當前配置的一個操做瀏覽器
以上四個級別一一對應下圖中1,2,3,4標記位:服務器
瀏覽器將CORS請求分紅兩類:簡單請求(simple request)和非簡單請求(not-so-simple request), 如何區別這二者可參考:[HTTPS]跨域資源共享 CORS 詳解 -[轉自:阮一峯的網絡日誌 » 首頁 » 檔案 http://www.ruanyifeng.com/blog/2016/04/cors.html]微信
瀏覽器直接發出CORS請求。會在Requst頭信息之中,增長一個Origin
字段,值爲瀏覽器中的URL。服務器根據這個值,決定是否贊成此次請求。網絡
Origin
指定的域名,不在許可範圍內,服務器會返回一個正常的HTTP迴應(200的空返回)。瀏覽器發現,這個迴應的頭信息沒有包含Access-Control-Allow-Origin
字段,就知道出錯了,從而拋出一個CORS error錯誤。Origin
指定的域名,在許可範圍內,服務器返回的響應,會多出幾個Access-Control-*
頭信息字段。CORS error 瀏覽器表現(打開開發者模式窗口可見 F12) | ![]() |
GET CORS 請求錯誤,不包含Access-Control-Allow-Origin 字段 |
![]() |
GET CORS 請求成功,包含Access-Control-Allow-Origin 字段 |
![]() |
非簡單請求是那種對服務器有特殊要求的請求,好比請求方法是POST, PUT
或DELETE
,或者Content-Type
字段的類型是application/json
。非簡單請求的CORS請求,會在正式通訊以前,增長一次HTTP查詢請求,稱爲"預檢"請求(preflight)。"預檢"請求用的請求方法是OPTIONS
,表示這個請求是用來詢問的。頭信息裏面,關鍵字段是Origin
,表示請求來自哪一個源。
Origin
、Access-Control-Request-Method
和Access-Control-Request-Headers
字段之後,確認容許跨源請求,就能夠作出迴應。關鍵的是Access-Control-Allow-Origin
字段,表示能夠請求數據。也能夠爲星號,表示贊成任意跨源請求。OPTIONS請求跨域失敗 | ![]() |
OPTIONS請求跨域成功 | ![]() |
POST 請求跨域成功 | ![]() |
(PS: 以上數據在測試中經過Fiddler抓包獲取到OPTIONS和POST請求數據)
API Management cross domain policies:https://docs.microsoft.com/en-us/azure/api-management/api-management-cross-domain-policies#CORS
跨域資源共享 CORS 詳解:http://www.ruanyifeng.com/blog/2016/04/cors.html