在POST之前在CORS请求上使用OPTION请求的原因是什么？ [英] What is the reason behind using OPTION request before POST on CORS requests?
问题描述
在实际 POST ， UPDATE ， PUT 或<之前发送 OPTION 请求的原因是什么调用其他域时，em> DELETE 请求？ （所以关于CORS请求）我知道它应该检查服务器是否可以处理真实请求，但为什么不立即发送真实请求？
What is the reason behind sending an OPTION request before the actual POST, UPDATE, PUT or DELETE request when a different domain is called? (So on CORS requests) I know it supposed to check whether the server can process the real request but why not send just the real request immediately?
我考虑过的一些原因：
- 参见如果支持该方法
- 发送实际请求将返回相同的状态代码，因此
不需要先发送OPTION请求。 - 检查用户是否允许发送请求
- 没有意义，因为没有发送auth标头选项请求
- See if the method is supported
- Sending the real request will return the same status code, so no need to send OPTION request first.
- Check if the user allowed to send the request
- Make no sense as no auth headers are sent with the OPTION requests
- 没有意义，因为在处理数据之前检查身份验证规则。
- 这是它现在的工作原理，但为什么不发送请求，我们可以阅读来自真实请求的错误。
- 这是有效的唯一原因。使用选项请求将阻止不必要地将发布数据发送到服务器。但是我认为这在99％的时间里都不是问题，因为只发送了一小部分数据。
有人可以了解浏览器供应商实施的原因吗？调用其他域时，OPTION 请求？
Can someone shed some light on the reasons why browser vendors implemented OPTION requests when calling a different domain?
推荐答案
CORS基本上是一个浏览器安全功能而非服务器端。
CORS is a basically a browser security feature not server side.
默认情况下，浏览器不允许某些跨源请求。您正在与之交谈的服务器可以发布使用跨源请求是否安全，但是客户端了解并使用该信息，因此提供的保护不是服务器。
By default the browser will NOT allow certain cross origin requests. The server you're talking to can publish whether or not it's safe to use cross origin requests but it's the client that understands and uses that information and therefore provides the protection not the server.
因此，对于GET请求，您可以获取资源，检查CORS标头，然后根据标头决定是否处理它。很好很简单。
So for a GET request you can get the resource, check the CORS header and then decide whether to process it or not based on the header. Nice and simple.
对于POST（或其他更改）事件，它并不那么简单。你发出POST请求，服务器处理它（记住服务器不关心CORS，只关心浏览器）并发回响应。浏览器看到CORS未启用并忽略响应，但到那时为时已晚 - POST请求已在服务器端处理，所有阻止的是显示已处理的结果。因此，对于网上银行应用程序，例如，转移资金的恶意请求意味着资金将被转移，但您的浏览器将忽略成功转移资金的响应 - 大量的损失是在资金消失和恶意请求时完成的反正可能会忽略响应！
For a POST (or other changing) event it's not so simple. You make the POST request, the server process it (remember the server doesn't care about CORS, only the browser) and sends back the response. The browser sees CORS is not enabled and ignores the response but by that point it's too late - the POST request has been processed at the server side and all that's prevented is the display of the results that it's been processed. So for an online banking application, for example, a malicious request to transfer funds means the funds will be transferred but your browser will ignore the "funds transferred successfully" response - big deal the damage is done as the money is gone and the malicious request would likely have ignored the response anyway!
所以你不能发送请求，直到你知道响应的CORS标头是什么 - 这需要发送请求！鸡肉和鸡蛋的情况。
So you can't send the request until you know what the CORS header will be on the response - which requires sending the request! Chicken and egg situation.
因此，浏览器会向同一地址发送一个OPTIONS请求，不会更改任何类似POST请求的地址，但确实返回CORS标头。之后，浏览器知道发送真实请求是否安全。
So the browser sends an OPTIONS request to the same address which doesn't change anything like a POST request might, but does return the CORS header. After that the browser knows whether it's safe to send the real request.
并且说服务器没有实现CORS安全性的原因是它非常容易改变推荐者标题，所以它无论如何都不会提供任何保护。服务器将具有其他安全功能（例如，检查会话是有效的并且有权发出请求）但是CORS旨在防止的攻击是这些无法帮助的攻击（例如，用户 登录在另一个标签上的网上银行）。
And btw the reason that a server doesn't implement CORS security is that it's incredibly easy to alter the Referrer header so it wouldn't offer any protection anyway. The server will have other security features (e.g. checking session is valid and authorised to make the request) but an attack that CORS is designed to prevent is one where these don't help (e.g. user is logged in to their online banking on another tab).
这篇关于在POST之前在CORS请求上使用OPTION请求的原因是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
