在CORS请求的POST之前使用OPTION请求的原因是什么？

Question

什么是背后的实际POST，UPDATE，PUT或DELETE请求时不同的域调用之前发送OPTION请求的原因？ （所以CORS请求）我知道它应该检查服务器是否可以处理真正的请求，但为什么不立即发送真正的请求？

一些原因，我曾经想过：

1. 看看该方法支持
2. 发送真正的请求将返回相同的状态代码，所以 无需首先发送OPTION请求。
3. 检查用户是否允许发送请求
   • 没有任何意义，因为没有身份验证头与OPTION发送请求在服务器上
4. 防止重负载
   • 没有意义，因为在处理数据之前检查授权规则。
5. 要检查是否请求头和原产地允许
   • 这是它是如何工作了，但是又为什么不直接发送请求，我们可以从实际的请求读取错误。
6. 禁止发送POST数据，如果它不会被处理
   • 这是唯一的原因是什么是有效的。使用选项请求将阻止不必要地将发布数据发送到服务器。不过，我认为在99％的时间内这不是问题，因为只发送一小块数据。

有人可以提供一些线索上的原因，浏览器厂商调用不同的域时实施OPTION请求？

Answer 1

CORS基本上是一个浏览器安全功能，而不是服务器端。

默认情况下，浏览器不会允许某些交叉源请求。您正在与之通话的服务器可以发布使用交叉源请求是否安全，但它是理解并使用该信息的客户端，因此提供的不是服务器的保护。

因此，对于GET请求，您可以获取资源，检查CORS头，然后根据头确定是否处理它。很好很简单。

对于POST（或其他更改）事件并不那么简单。你做POST请求，服务器处理它（记住服务器不关心CORS，只关心浏览器）并且发回响应。浏览器发现CORS没有启用并且忽略了响应，但是由于这一点太晚了 - POST请求已经在服务器端进行了处理，并且所有阻止的都是显示处理结果。例如，对于在线银行应用程序来说，恶意请求转移资金意味着资金将被转移，但您的浏览器将忽略“转移资金成功”的回应 - 重大损失是在资金消失和恶意请求无论如何，可能都会忽略回应！

所以你不能发送请求，直到你知道什么CORS头将在响应 - 这需要发送请求！鸡和鸡蛋的情况。

因此，浏览器发送一个OPTIONS请求到不像一个POST请求改变任何可能同一个地址，但确实返回CORS头。之后，浏览器知道发送真实请求是否安全。

而顺便说一句，服务器没有实现CORS安全的原因是，它很容易改变引用头，因此它不会提供任何保护。服务器将具有其他安全功能（例如，检查会话有效并被授权发出请求），但是CORS旨在防止的攻击是这些攻击不起作用的攻击（例如，用户是已登录到其在线银行另一个选项卡）。