Content-Type是'text / plain'还是'application / json'为什么有关系？

表单支持的三种内容类型（enctype）如下：

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

如果表单是由Web服务器上的处理程序接收的，并且不是上述内容类型之一，则可以假定发送该表单的是AJAX请求，而不是HTML<form />标记。

因此，如果现有的pre-CORS之前的系统使用内容类型作为确保请求不是跨站点的方法，以防止跨站点请求伪造（CSRF），那么CORS规范的作者就不希望将任何新的安全漏洞引入现有网站。为此，他们坚持要求此类请求启动预检，以确保浏览器和服务器首先兼容CORS。

不管POST是否破坏了数据库，它只关心浏览器不能读取该操作的输出

非常正确。默认情况下，浏览器遵循“相同来源策略”。CORS放宽了此限制，允许另一个Origin读取AJAX做出的响应。

为什么根本有飞行前要求？

如前所述，要确保客户端和服务器都与CORS兼容，并且不仅要发送HTML表单，而且始终可以跨域提交。

例如，这一直有效。example.com张贴至example.org以下表格：

<form method="post" action="//example.org/handler.php" />

仅仅在响应中检查“ Access-Control-Allow-Cross-Origin-Request：true”之类的标题就不够了吗？

由于CSRF向量。通过检查浏览器是否可以发送预检，它可以确保跨域请求在浏览器发送之前得到授权（通过检查CORS响应标头）。这样一来，浏览器就可以保护当前用户的会话-请记住，此处的攻击者不是运行该浏览器的攻击者，受害者是通过CSRF攻击运行该浏览器的，因此，这种可操纵的浏览器无法正确检查CORS标头或欺骗性内容。预检对于攻击者运行自己没有任何好处。同样，预检可以使CSRF缓解措施（例如自定义标头）起作用。

总结一下：

HTML表单跨域

• 只能用特定的被发送enctype的
• 不能有自定义标题
• 浏览器将不带预检就发送它，因为有关<form>提交的所有内容都是标准的（或者像CORS所说的那样“简单”）
• 如果服务器处理程序收到此类表格的请求，它将对其进行处理

AJAX跨源

• 仅可通过CORS
• 某些浏览器的早期版本（例如IE 8和9）可以发送跨域请求，但不能使用非标准标头或enctype。
• enctype在完全支持的浏览器中可以具有自定义标头和
• 为了确保跨域AJAX请求不会欺骗同域AJAX请求（请记住，跨域起源以前是不可能的），如果AJAX请求不简单，则浏览器将向Google发送预检信息确保允许
• 如果服务器处理程序接收到请求，它将对它进行处理，但只有在通过预检检查后才会执行，因为初始请求将使用OPTIONS动词发出，并且直到浏览器同意服务器正在与CORS对话时，它才会发送实际的GET或开机自检