【Azure API 管理】APIM CORS策略设置后，跨域请求成功和失败的Header对比实验

在文章“”中分析了CORS返回空200的问题后，进一步对APIM的CORS策略进行验证，深入学习<>。

首先，我们已经学习到CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，整个CORS通信过程，都是浏览器自动完成，不需要用户参与。而服务端则不同，它是实现CORS通信的关键。只要服务器实现了CORS接口，就可以跨源通信。本文中服务端就是Azure APIM (https://portal.azure.cn/#blade/HubsExtension/BrowseResource/resourceType/Microsoft.ApiManagement%2Fservice)。

在APIM中，是通过配置策略(Policy)来实现CORS设置的。在APIM门户中由多种级别可以开启CORS，可以根据API的使用情况灵活配置不同的跨域策略(cors policy)。

1) 产品级别（Products Policies)：作用范围为产品下的全部API

2) All APIs 级别 （Inbound processing）：作用范围为当前APIM中的所有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]

对比一：简单请求 GET

Origin

OriginAccess-Control-Allow-OriginOriginAccess-Control-* 

Access-Control-Allow-OriginAccess-Control-Allow-Origin

对比二：非简单请求 OPTIONS, POST

PUTDELETEContent-Typeapplication/jsonOPTIONSOrigin

OriginAccess-Control-Request-MethodAccess-Control-Request-HeadersAccess-Control-Allow-Origin

OPTIONS请求跨域失败
OPTIONS请求跨域成功
POST 请求跨域成功

（PS: 以上数据在测试中通过Fiddler抓包获取到OPTIONS和POST请求数据）

结论：

在遇见CORS报错后，查看请求的返回内容即可得出是否在服务端正确配置源站点 ​​​​​  ​​​​​​​​​​​​​​  ​​​​​​​ ​​​​​​​​​​​​​

参考资料