跨域资源共享是一种允许网页向另一个域（从维基百科 https://en.wikipedia.org/wiki/Cross-origin_resource_sharing).
过去几天我一直在摆弄 CORS，我想我对一切的工作原理有了很好的理解。
所以我的问题不是关于 CORS / 预检如何工作，而是关于将预检作为新请求类型的原因。我不明白为什么服务器 A 需要向服务器 B 发送预检（PR）只是为了查明真正的请求（RR）是否会被接受 - B 肯定有可能接受/拒绝 RR 而无需任何先前的公关。
经过一番搜索后我发现这件作品 https://www.w3.org/TR/cors/#preflight-request的信息在www.w3.org http://www.w3.org(7.1.5)：
为了保护资源免受在本规范存在之前无法源自某些用户代理的跨源请求的影响
发出预检请求是为了确保资源知道这一点
规格。
我发现这是有史以来最难理解的句子。我的解释（最好称之为“最佳猜测”）是，它是为了保护服务器 B 免受来自不了解规范的服务器 C 的请求。
有人可以解释一下场景/展示 PR + RR 比单独 RR 解决得更好的问题吗？
我花了一些时间对飞行前请求的目的感到困惑，但我想我现在已经明白了。
关键的见解是预检请求不是security事物。相反，他们是一个不改变规则 thing.
预检请求与安全性无关，并且与现在正在开发的具有 CORS 意识的应用程序无关。相反，预检机制有利于开发的服务器without对 CORS 的感知，它充当客户端和服务器之间的健全性检查，确保它们都支持 CORS。 CORS 的开发人员认为，有足够多的服务器依赖于他们永远不会收到的假设，例如他们发明了预检机制以允许双方选择加入的跨域删除请求。他们认为，简单地启用跨域调用的替代方案会破坏太多现有应用程序。
这里有三种情况：
旧服务器，不再开发，并且在 CORS 之前开发。这些服务器可能会假设他们永远不会收到例如跨域 DELETE 请求。这种场景是预检机制的主要受益者。是的，这些服务可能已经被恶意或不合格的用户代理滥用（CORS 无法改变这一点），但在具有 CORS 的世界中，预检机制提供了额外的“健全性检查”，以便客户端和服务器不会这样做。打破是因为网络的基本规则已经改变。
仍在开发中的服务器，但包含大量旧代码，并且审核所有旧代码以确保其在跨域世界中正常工作是不可行/不合需要的。这种情况允许服务器逐步选择加入 CORS，例如通过说“现在我将允许这个特定的标头”、“现在我将允许这个特定的 HTTP 动词”、“现在我将允许发送 cookie/auth 信息”等。这种情况受益于预检机制。
编写时考虑到 CORS 的新服务器。根据标准安全实践，服务器必须在面临以下情况时保护其资源：any传入请求——服务器不能相信客户端不会做恶意的事情。这种情况不会受益于预检机制：预检机制不会为已正确保护其资源的服务器带来额外的安全性。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
