用 jQuery 发送一个“简单”的 POST 请求，但还是得到了 CORS答案

【问题标题】：Sending a 'simple' POST request with jQuery, but getting CORS anyway用 jQuery 发送一个“简单”的 POST 请求，但还是得到了 CORS
【发布时间】：2017-05-23 06:02:18
【问题描述】：

CORS 规范规定，如果 HTTP 请求被认为是“简单的”，则不需要 CORS 和/或预检。

我正在尝试执行似乎具有以下条件的 HTTP 请求：

我没有设置自定义 HTTP 标头。
我正在使用POST 方法。
我正在使用application/x-www-form-urlencoded。

代码示例：

$.ajax({
  type: 'POST',
  url: 'http://example.org/',
  data: {foo: 'bar'}
});

但是，在运行此程序时，请求仍会使用 OPTIONS 进行预检（失败）。我有什么明显的遗漏吗？

一些简单请求的引用：

【问题讨论】：

我真的很想看到有人给出一个 ajax POST 的例子，当源域不被允许时，有效负载不会触发 CORS。根据我对 CORS 目的的了解，我想不出允许这样做的情况。
stackoverflow.com/questions/7936610/…
@2by2 这是一个肮脏的解决方法。不会用 10 英尺的民意调查 jsonp。
JSONP 无论如何都不适用于发布请求。对简单的 GET 请求使用 JSONP 没有问题。
服务器是否在响应中发送Access-Control-Allow-Origin 标头？即使是简单的请求，也需要这样做。

标签： javascript jquery ajax cross-domain

【解决方案1】：

CORS 限制会影响从一个域到另一个域的所有请求。示例：本地主机 -> example.com。我最终只是转到了我的 example.com 服务器端代码，并确保我启用了来自 myotherexample.com 的请求，我从中进行调用。在本地开发时使用 CORS 标头执行此操作

Access-Control-Allow-Origin: *

另一个准备生产的例子

Access-Control-Allow-Origin: https://myotherexample.com

【讨论】：

不符合规范。 developer.mozilla.org/en-US/docs/Web/HTTP/…
从一个域到另一个域的请求将设置 Referrer 标头，我不认为它是该规范中的白名单标头。
TxRegex 和 Taplar 都是正确的。没有简单的请求这样的事情。向其他域发出请求时，您总是会受到 CORS 的打击。
只有在 jQuery 手动设置此标头时才会如此。浏览器自动设置的任何协议级标头都将被排除在外。否则，在 CORS 出现之前，这将行不通。
你是说浏览器没有正确实现规范还是我读错了规范？

【解决方案2】：

我在重新阅读文档时意识到自己的错误。

我正在做的确实是一个简单的请求。该请求实际上是在没有OPTIONS 请求的情况下发送到服务器并成功的！

但是，当回复返回时，我不允许阅读回复。所以简单和非简单 CORS 请求的真正区别是：

对于简单的请求，不需要预检，但服务器仍需要使用 CORS 标头进行响应。

所以我的选择如下：

我忽略了这个错误。毕竟请求成功了，我就是看不懂响应。
我还是在服务器端实现了 CORS。就我而言，我不能，因为我无法控制目标服务器。
我使用 html 表单提交数据，在其上调用 .submit() 并定位隐藏的 iFrame。
我通过我控制的服务器代理请求。

未来：

我认为，但我不确定新的 Fetch API 是否还允许您跨域发出 HTTP 请求、选择退出 CORS 并被拒绝访问HTTP 响应。如果这是正确的，那么这将是（对我而言）执行此操作的理想方式。但我不能 100% 确定这是否确实如此。

【讨论】：

我希望 #3 也会产生 CORS。
@Taplar 嗯，不，它不会。但是您仍然无法阅读响应，您将被拒绝访问。
CORS 不能帮助您访问 iFrame 的内容。这就是区别。这不是 cors 问题，只是一个不同但相似的问题。
@Darkrum 对于 CORS，有一个“简单”的请求。我不确定你在说什么。是的，如果你想避免错误，它仍然必须支持 CORS，但它仍然可以工作，并且与非简单请求仍有很大不同。
除了，在谈到 cors 时。简单请求与复杂请求的区别在于，简单请求不需要预检。这是一个非常显着的差异。