在阅读了很多关于 CORS 和飞行前请求的信息后，我仍然不太明白为什么进行飞行前会有一些例外。为什么 Content-Type 是 'text/plain' 或 'application/json' 很重要？
如果我猜对了，CORS 的值是限制返回的数据（它不关心 POST 是否破坏了数据库，它只关心浏览器无法读取该操作的输出）。但如果这是真的（可能不是），为什么会有飞行前的请求呢？仅仅检查响应中的“Access-Control-Allow-Cross-Origin-Request: true”这样的标头还不够吗？
迄今为止我在CORS - What is the motivation behind introducing preflight requests? 问题中找到的最佳答案，但对我来说仍然有点困惑。
【问题讨论】：
为什么 Content-Type 是 'text/plain' 或 '应用程序/json'？
三个content types (enctype) supported by a form如下：
application/x-www-form-urlencodedmultipart/form-datatext/plain如果 Web 服务器上的处理程序接收到表单，并且它不是上述内容类型之一，则可以假定它是发送表单的 AJAX 请求，而不是 HTML <form /> 标记.
因此，如果现有的 pre-CORS 系统为了防止Cross-Site Request Forgery (CSRF) 使用内容类型作为确保请求不是跨站点的方法，那么 CORS 规范的作者不想引入现有网站的任何新安全漏洞。他们通过坚持此类请求启动预检来确保浏览器和服务器首先兼容 CORS 来做到这一点。
它不关心 POST 是否破坏了数据库，它只关心那个 浏览器无法读取该操作的输出
完全正确。默认情况下，浏览器遵循Same Origin Policy。 CORS 放宽了这个限制，允许另一个 Origin 读取 AJAX 的响应。
为什么会有飞行前请求？
如前所述，确保客户端和服务器都兼容 CORS，而不仅仅是发送的 HTML 表单始终能够跨域提交。
例如这一直有效。 example.com POSTing 到 example.org 的表单：
<form method="post" action="//example.org/handler.php" />
仅此还不够 检查类似“Access-Control-Allow-Cross-Origin-Request:”的标头 回复中的“真实”？
因为 CSRF 向量。通过检查浏览器是否可以发送预检，它确保跨域请求在浏览器发送之前被授权（通过检查 CORS 响应标头）。这使浏览器能够保护当前用户的会话 - 请记住，这里的攻击者不是运行浏览器的人，受害者在 CSRF 攻击中运行浏览器，因此被操纵的浏览器无法正确检查 CORS 标头或欺骗预检对攻击者自己运行没有任何好处。同样，预检使 custom headers 等 CSRF 缓解措施发挥作用。
总结：
enctype's 一起发送<form> 提交的所有内容都是标准的（或 CORS 所说的 "simple"）enctype'senctype
【讨论】：