我在过去几天里一直在使用CORS，我认为我对这一切都有很好的理解。
所以我的问题不是关于CORS / preflight工作，它是关于推出preflights作为一个新的请求类型的原因。我没有看到任何原因，为什么服务器A需要发送预检(PR)到服务器B只是为了找出是否将接受真实请求(RR) – B当然可能接受/拒绝RR没有任何以前的公关。
搜索了一下后，我在www.w3.org(7.1.5)找到了this piece的信息：
To protect resources against cross-origin requests that Could not originate from certain user agents before this specification existed a
preflight request is made to ensure that the resource is aware of this
specification.
我觉得这是最难理解的句子。我的解释(应该更好地称之为“最好的猜测”)是，它是关于保护服务器B对来自不知道规范的服务器C的请求。
有人可以请解释一个情况/显示PR RR解决比RR单独更好的问题吗？
关键的见解是，预检请求不是一个安全的事情。相反，他们是一个不改变规则的事情。
预检请求与安全无关，并且它们对于现在正在开发的应用程序没有影响，意识到CORS。相反，预检机制有利于在没有意识到CORS的情况下开发的服务器，并且它用作客户端和服务器之间的可靠性检查，它们都是CORS感知的。 CORS的开发者认为有足够的服务器，依赖于他们永远不会接收的假设，例如。跨域DELETE请求，他们发明了预检机制以允许双方选择加入。他们认为，替代方案，这将是简单地启用跨域调用，将打破太多的现有应用程序。
这里有三种情况：
>旧服务器，不再处于开发中，并在CORS之前开发。这些服务器可以假设他们永远不会接收。跨域DELETE请求。这种情况是预检机制的主要受益者。是的，这些服务可能已经被恶意或不合格的用户代理滥用(并且CORS没有改变这一点)，但是在一个使用CORS的世界中，预检机制提供了一个额外的“健康检查”，使客户端和服务器不因为网络的基本规则已经改变。>仍在开发中的服务器，但它们包含大量旧代码，因此对于所有旧代码进行审计以确保其在跨域环境中正常工作是不可行/不可取的。这种情况允许服务器逐步选择加入CORS，例如通过说“现在我将允许这个特定的头”，“现在我将允许这个特定的HTTP动词”，“现在我将允许发送cookie / auth信息”等。这种情况下从预检机制。>使用CORS意识书写的新服务器。根据标准的安全实践，服务器必须在任何传入请求面前保护其资源 – 服务器不能信任客户端不做恶意的事情。此方案不会从预检机制中受益：预检机制不会对已正确保护其资源的服务器带来额外的安全性。