引入飞行前CORS请求背后的动机是什么？

Question

跨源资源共享是一种允许web页面对另一个域（从wikipedia）进行XMLHttpRequest的机制。

最近几天我一直在摆弄CORS，我想我已经很好地理解了一切的工作原理。

所以我的问题不是关于CORS/preflight是如何工作的，而是关于将preflight作为一种新的请求类型背后的原因。我看不出为什么服务器A需要向服务器B发送一个预置(PR)来了解真实的请求(RR)是否会被接受-B当然有可能在没有任何预置PR的情况下接受/拒绝RR。

我在www.w3.org(7.1.5):

为了保护资源不受在此规范存在之前不能从某些用户代理发起的跨源请求的影响，提出一个预置请求以确保资源知道此规范。

我发现这是有史以来最难理解的句子。我的解释（应该更好地称之为“最佳猜测”）是，它是关于保护服务器B不受来自服务器C的请求的影响，而服务器C不知道该规范。

谁能解释一个场景/展示一个PR+RR比RR单独解决更好的问题吗？

Answer 1

我花了一段时间对飞行前请求的目的感到困惑，但我想我现在明白了。

关键的洞察力是，飞行前请求不是一个安全问题。相反，他们是一个不改变规则的东西。

飞行前的请求与安全性无关，它们与现在正在开发的应用程序也没有关系。相反，预飞行机制有利于那些在没有CORS意识的情况下开发的服务器，它的作用是在客户机和服务器之间检查它们是否都是CORS意识的。CORS的开发人员认为，有足够多的服务器依赖于他们永远不会接收的假设，例如，他们发明了预置机制来允许双方选择加入的跨域删除请求。他们认为，如果只是简单地启用跨域调用，就会破坏太多现有的应用程序。

这里有三种场景：

>

旧服务器，不再在开发中，并且在CORS之前开发。这些服务器可能会假设它们永远不会接收到（例如）跨域删除请求。这种情况是预飞行机制的主要受益者。是的，这些服务可能已经被恶意或不符合要求的用户代理滥用了（而CORS并没有改变这一点），但是在有CORS的世界中，预飞行机制提供了一个额外的“健全性检查”，这样客户端和服务器就不会因为web的基本规则已经改变而破坏。

仍在开发中但包含大量旧代码的服务器，对其进行审计以确保其在跨域环境中正常工作是不可行的/不需要的。该场景允许服务器逐步选择加入CORS，例如，通过说“现在我将允许这个特定的头”、“现在我将允许这个特定的HTTP谓词”、“现在我将允许发送Cookie/Auth信息”等。

使用CORS编写的新服务器。根据标准的安全实践，服务器必须在面对任何传入的请求时保护其资源--服务器不能信任客户机不做恶意的事情。此场景不能从预置机制中受益：预置机制不会为已正确保护其资源的服务器带来额外的安全性。