ajax - 引入预检 CORS 请求背后的动机是什么？

跨域资源共享是一种允许网页向另一个域(来自 wikipedia )发出 XMLHttpRequests 的机制。

在过去的几天里，我一直在摆弄 CORS，我想我对一切的工作原理有了很好的了解。

所以我的问题不是关于 CORS/预检如何工作，而是关于 提出预检作为新请求类型 的原因。我看不出为什么服务器 A 需要向服务器 B 发送预检 (PR) 只是为了确定真正的请求 (RR) 是否会被接受 - B 肯定有可能接受/拒绝 RR 而没有任何先前的 PR。

经过一番搜索，我在 www.w3.org (7.1.5) 上找到了 this piece 的信息:



我发现这是有史以来最难理解的句子。我的解释(最好将其称为“最佳猜测”)是关于保护服务器 B 免受来自不了解规范的服务器 C 的请求。

有人可以解释一个场景/展示一个 PR + RR 比单独 RR 解决的问题更好的问题吗？

最佳答案

我花了一些时间对预检请求的目的感到困惑，但我想我现在已经明白了。

关键的见解是预检请求不是 安全性 的事情。相反，它们是 不改变规则 的东西。

预检请求与安全无关，它们与现在正在开发的应用程序无关，并具有 CORS 意识。相反，预检机制有益于在不了解 CORS 的情况下开发的服务器，并且它用作客户端和服务器之间的完整性检查，它们都可识别 CORS。 CORS 的开发人员认为，有足够多的服务器依赖于他们永远不会收到的假设，例如他们发明了预检机制以允许双方选择加入的跨域 DELETE 请求。他们认为替代方案，即简单地启用跨域调用，会破坏太多现有的应用程序。

这里有三种情况:

老服务器，不再开发，CORS之前开发。这些服务器可能会假设他们永远不会收到例如跨域 DELETE 请求。 这个场景是预检机制的主要受益者。 是的，这些服务可能已经被恶意或不符合标准的用户代理滥用(而 CORS 没有做任何改变)，但在具有 CORS 的世界中，预检机制提供了额外的“健全性检查”，以便客户端和服务器不会“t 中断是因为网络的基本规则发生了变化。

仍在开发中的服务器，但其中包含大量旧代码，并且不可行/不希望审核所有旧代码以确保其在跨域世界中正常工作。这种情况允许服务器逐步选择加入 CORS，例如通过说“现在我将允许此特定 header ”、“现在我将允许此特定 HTTP 动词”、“现在我将允许发送 cookie/身份验证信息”等。 此方案受益于预检机制.

新的服务器，写有 CORS 意识。根据标准的安全实践，面对任何传入的请求，服务器必须保护其资源——服务器不能相信客户端不会做恶意的事情。 这种情况不能从预检机制中受益 :预检机制没有给适当保护其资源的服务器带来额外的安全性。

关于ajax - 引入预检 CORS 请求背后的动机是什么？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/15381105/