CORS - 引入预检请求的动机是什么？ [英] CORS - What is the motivation behind introducing preflight requests?
问题描述
Cross-origin resource sharing is a mechanism that allows a web page to make XMLHttpRequests to another domain (from wikipedia), and it's pretty important (from me :).
我在过去几天里一直在使用CORS，认为我有一个很好的理解一切如何工作。
I've been fiddling with CORS for the last couple of days and I think I have a pretty good understanding of how everything works.
因此，我的问题不是CORS / preflight如何工作，而是关于作为新的请求类型提出preflights的原因。我没有看到任何原因为什么服务器A需要发送预检（PR）到服务器B只是为了找出是否将接受真实请求（RR） - B当然可能接受/拒绝RR没有任何以前的公关。
So my question is not about how CORS / preflight work, it's about the reason behind coming up with preflights as a new request type. I fail to see any reason why server A needs to send a preflight (PR) to server B just to find out if the real request (RR) will be accepted or not - it would certainly be possible for B to accept/reject RR without any prior PR.
搜索后，我发现了这篇文章的信息，请访问www.w3.org（7.1.5）：
After searching quite a bit I found this piece of information at www.w3.org (7.1.5):
在此规范存在之前不能从某些用户代理产生一个
预检请求以确保该资源知道这个
规范。
我发现这是最难理解的句子。我的解释（应该更好地称之为最好的猜测）是，它是关于保护服务器B对来自不知道规范的服务器C的请求。
I find this is the hardest to understand sentence ever. My interpretation (should better call it 'best guess') is that it's about protecting server B against requests from server C that is not aware of the spec.
有人可以解释一个场景/显示PR + RR比单独使用RR更好的问题吗？
Can someone please explain a scenario / show a problem that PR + RR solves better than RR alone?
推荐答案
我花了一些时间对预检请求的目的感到困惑，但我想我现在有了。
I spent some time being confused as to the purpose of the preflight request but I think I've got it now.
关键的见解是，预检请求不是安全的东西。相反，他们是一个不改变规则的事情。
The key insight is that preflight requests are not a security thing. Rather, they're a not-changing-the-rules thing.
预检请求与安全无关，它们对CORS的意识与现在正在开发的应用程序没有关系。相反，预检机制使得被开发的服务器受益于对CORS的意识，并且它作为在客户端和服务器之间的可靠性检查，它们都是CORS感知的。 CORS的开发人员认为，有足够的服务器，依赖于他们永远不会接收的假设，例如。跨域DELETE请求，他们发明了预检机制以允许双方选择加入。他们认为，替代方案，只是简单地启用跨域调用，将会破坏太多的现有应用程序。
Preflight requests have nothing to do with security, and they have no bearing on applications that are being developed now, with an awareness of CORS. Rather, the preflight mechanism benefits servers that were developed without an awareness of CORS, and it functions as a sanity check between the client and the server that they are both CORS-aware. The developers of CORS felt that there were enough servers out there that were relying on the assumption that they would never receive, e.g. a cross-domain DELETE request that they invented the preflight mechanism to allow both sides to opt-in. They felt that the alternative, which would have been to simply enable the cross-domain calls, would have broken too many existing applications.
这里有三种情况： p>
There are three scenarios here:
-
旧服务器，不再处于开发阶段，在CORS之前开发。这些服务器可以假设他们永远不会接收。跨域DELETE请求。 这种情况是预检机制的主要受益者。是的，这些服务可能已经被恶意或不合格的用户代理滥用（并且CORS不会改变这一点），但在一个有CORS
Old servers, no longer under development, and developed before CORS. These servers may make assumptions that they'll never receive e.g. a cross-domain DELETE request. This scenario is the primary beneficiary of the preflight mechanism. Yes these services could already be abused by a malicious or non-conforming user agent (and CORS does nothing to change this), but in a world with CORS the preflight mechanism provides an extra 'sanity check' so that clients and servers don't break because the underlying rules of the web have changed.
预检机制提供了额外的健全检查，以便客户端和服务器不会中断，因为网络的基本规则已更改。仍然在开发中，但包含了很多旧的代码，对于它是不可行的/不可取的审计所有的旧代码，以确保它在跨域的世界正常工作。这种情况允许服务器逐步选择加入CORS，例如通过说现在我会允许这个特定的标题，现在我将允许这个特定的HTTP动词，现在我将允许发送cookie / auth信息等。预检机制。
Servers that are still under development, but which contain a lot of old code and for which it's not feasible/desirable to audit all the old code to make sure it works properly in a cross-domain world. This scenario allows servers to progressively opt-in to CORS, e.g. by saying "Now I'll allow this particular header", "Now I'll allow this particular HTTP verb", "Now I'll allow cookies/auth information to be sent", etc. This scenario benefits from the preflight mechanism.
使用CORS意识书写的新服务器。根据标准安全实践，服务器必须在面对任何传入请求时保护其资源 - 服务器不能信任客户端不进行恶意的事情。 此方案不会从预检机制中受益：预检机制不会对已正确保护其资源的服务器带来额外的安全性。
New servers that are written with an awareness of CORS. According to standard security practices, the server has to protect its resources in the face of any incoming request -- servers can't trust clients to not do malicious things. This scenario doesn't benefit from the preflight mechanism: the preflight mechanism brings no additional security to a server that has properly protected its resources.
这篇关于CORS - 引入预检请求的动机是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
