我们好，我是后端黄瓜哥。

即使相混思路（Cross-Origin Policy）的存有，应用程序在两个搜索引擎下推送另两个搜索引擎的 Ajax 允诺时，回到的统计数据一般而言会被应用程序截击，让开发人员难以领到回到结论。

这儿说 “一般而言”，原因在于应用程序附加提供更多了一类能恒定采用 Ajax 允诺非相混搜索引擎USB的监督机制，也是他们接下去没错的跨源数据共享（CORS, Cross-Origin Resource Sharing）。

CORS 会在上图中的第二步中有所作为。

单纯而言，是允诺 b.com 的 HTTP 积极响应头表头中的许多头表头合乎很大准则，回到统计数据就不能被应用程序截击，允诺者能恒定赢得回到统计数据。

单纯允诺和非单纯允诺是浏览器收到布吕马允诺的三种相同的允诺形式，他们来介绍呵呵。

单纯允诺

推送的允诺合乎上面的大部份情形，就归属于单纯允诺。

允诺方法为其中一类：GET、POST、HEAD；除了应用程序自动设置的表头（比如 Connection），仅能人为设置允诺头表头 Accept、Accept-Language、Content-Language、Content-Type 这个集合内的值。允诺头表头 Content-Type 为其中一类：text/plain、 multipart/form-data、application/x-www-form-urlencoded；

（还有许多更多的琐碎的细节，比如脚本设置、特定应用程序相关的，这儿不展开，具体能查阅官方文档）

可能你会对这个准则的设计很感兴趣，其实它是为了 向后兼容，兼容许多之前没有 Ajax 时就能推送的布吕马允诺，比如 form 元素能够产生的允诺。

点击表单下的提交按钮，页面跳转然后推送允诺。这种写法非常古老了，即使会自动跳转页面且不能领到回到统计数据执行下一步的操作，实际开发基本上不能采用了

CORS 监督机制下，HTTP 积极响应头表头需要采用头表头 Access-Control-Allow-Origin，将它的值设置为：

*：任意搜索引擎都允许布吕马允诺。<origin>：具体的搜索引擎，这儿不能提供更多多个搜索引擎，只能提供更多两个搜索引擎。这也是能理解的，通过强制要求防止黑客得到服务端设置的白名单搜索引擎。他们不应该透露太多信息。服务端要实现布吕马白名单功能，就需要根据允诺头表头中动态返回该表头的值。

另外，如果允诺中携带了身份信息，也是 Cookie，不能采用 *，而需要指定具体搜索引擎。

这样设置后，他们就能恒定地领到其他搜索引擎USB回到的统计数据了。

上面他们再看看非单纯允诺。

非单纯允诺

不合乎简单允诺规定条件的允诺，是非单纯允诺。

对于单纯允诺，为了兼容，应用程序会直接将允诺收到去。但非单纯允诺没有兼容的需要，所以应用程序给它加上了严格的复杂监督机制。

在收到真正的允诺前，应用程序会先发两个 OPTION 允诺来探探路，这个允诺称为预检允诺（preflight）。

应用程序推送的允诺，会附加带下以下允诺头表头：

Access-Control-Request-Method：该表头告知服务端接下去要发起真正跨域允诺采用的 HTTP 方法。Access-Control-Request-Headers：该表头告知服务端，当前允诺采用的不合乎单纯允诺准则的头表头，比如采用 JSON 结构来作为统计数据的格式，预检请求就会带上上Access-Control-Request-Headers: content-type

上面是服务端的回合。

服务端领到了足够多的允诺方信息，然后就能考虑是否允许布吕马了。

服务端的积极响应头表头能携带上以下表头：

Access-Control-Allow-Origin：用法同上一节的单纯允诺说明。Access-Control-Allow-Methods：能推送的允诺方法。如 POST, GET, OPTIONS。Access-Control-Allow-Headers：能采用的头表头，如 X-PINGOTHER, Content-TypeAccess-Control-Max-Age: 86400：缓存的有效时长，单位为秒，设置后，在这段时间内都能免除预检允诺的推送。应用程序自身预设了两个最大缓存时间，防止回到的缓存时间过长（比如好几年）导致的安全问题。