发送 OPTION 的原因是什么？在实际 POST 之前请求, UPDATE , PUT或 DELETE当调用不同的域时请求？ (所以在 CORS 请求上)我知道它应该检查服务器是否可以处理真正的请求，但为什么不立即发送真正的请求呢？
我想到的一些原因:
- 查看是否支持该方法
- 发送真正的请求会返回相同的状态码，所以
无需发送
OPTION先请求。
- 检查用户是否允许发送请求
- 没有任何意义，因为
OPTION 没有发送任何身份验证 header 。要求
- 防止服务器负载过重
- 检查是否允许请求的 header 和来源
- 这就是它现在的工作方式，但为什么不直接发送请求，我们可以从真实请求中读取错误。
- 如果不处理则阻止发送 post 数据
- 这是有效的唯一原因。使用选项请求将防止不必要地将发布数据发送到服务器。但是我认为这在 99% 的时间里都不是问题，因为只发送了一小块数据。
有人可以阐明浏览器供应商实现 OPTION 的原因吗？调用不同域时的请求？
CORS 基本上是一种浏览器安全功能，而不是服务器端。
默认情况下，浏览器不允许某些跨源请求。您正在与之交谈的服务器可以发布使用跨源请求是否安全，但理解和使用该信息的是客户端，因此提供保护而不是服务器。
所以对于GET请求，你可以获取资源，检查CORS头，然后根据头决定是否处理它。漂亮而简单。
对于 POST(或其他更改的)事件，事情就没那么简单了。您发出 POST 请求，服务器处理它(记住服务器不关心 CORS，只关心浏览器)并发回响应。浏览器发现 CORS 未启用并忽略响应，但到那时为时已晚 - POST 请求已在服务器端处理，所有被阻止的是显示已处理的结果。因此，对于网上银行应用程序，例如，一个恶意的转账请求意味着资金将被转账，但您的浏览器将忽略“资金转账成功”的响应——重要的是，由于钱已经消失，恶意请求已经造成了损害无论如何都可能会忽略响应!
因此，在知道响应中的 CORS header 是什么之前，您无法发送请求 - 这需要发送请求!先有鸡还是先有蛋。
因此浏览器向同一地址发送一个 OPTIONS 请求，该地址不会像 POST 请求那样改变任何内容，但会返回 CORS header 。之后浏览器知道发送真实请求是否安全。
顺便说一句，服务器不实现 CORS 安全性的原因是更改 Referrer header 非常容易，因此无论如何它都不会提供任何保护。服务器将具有其他安全功能(例如，检查 session 是否有效并获得发出请求的授权)，但 CORS 旨在防止的攻击是这些功能无济于事的攻击(例如，用户已登录在另一个选项卡上转到他们的网上银行)。