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

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

在文章“从微信小程序访问APIM出现200空响应的问题中发现CORS的属性[terminate-unmatched-request]功能”中分析了CORS返回空200的问题后，进一步对APIM的CORS策略进行验证，深入学习<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标记位：

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

跨域请求成功 VS 失败

浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）, 如何区别这两者可参考：[HTTPS]跨域资源共享 CORS 详解 -[转自：阮一峰的网络日志 » 首页 » 档案 http://www.ruanyifeng.com/blog/2016/04/cors.html]

对比一：简单请求 GET

浏览器直接发出CORS请求。会在Requst头信息之中，增加一个Origin字段，值为浏览器中的URL。服务器根据这个值，决定是否同意这次请求。

如果Origin指定的域名，不在许可范围内，服务器会返回一个正常的HTTP回应(200的空返回)。浏览器发现，这个回应的头信息没有包含Access-Control-Allow-Origin字段，就知道出错了，从而抛出一个CORS error错误。
如果Origin指定的域名，在许可范围内，服务器返回的响应，会多出几个

Access-Control-*

头信息字段。

CORS error 浏览器表现(打开开发者模式窗口可见 F12)
GETCORS 请求错误，不包含`Access-Control-Allow-Origin`字段
GET CORS 请求成功，包含`Access-Control-Allow-Origin`字段

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

非简单请求是那种对服务器有特殊要求的请求，比如请求方法是POST, PUT或DELETE，或者Content-Type字段的类型是application/json。非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。"预检"请求用的请求方法是OPTIONS，表示这个请求是用来询问的。头信息里面，关键字段是Origin，表示请求来自哪个源。

如果服务器否定了"预检"请求，会返回一个正常200的HTTP回应，但是没有任何CORS相关的头信息字段。这时，浏览器就会认定，服务器不同意预检请求，因此触发一个错误.
如果服务器收到"预检"请求以后，检查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后，确认允许跨源请求，就可以做出回应。关键的是Access-Control-Allow-Origin字段，表示可以请求数据。也可以为星号，表示同意任意跨源请求。