根据 MDN ，POST请求不是如果Content-Type是 application/x-www-form-urlencoded ， multipart/form-data 或 text/plain 中的任何一个，则进行预检.
According to MDN, POST requests are not preflighted if the Content-Type is any of application/x-www-form-urlencoded, multipart/form-data, or text/plain.
但是 multipart/form-data 并不完全像 application/xml 一样不安全吗?例如，无论端点接受哪种内容类型，我都希望始终禁止对URL bank/money-orders/的跨域POST请求.
But isn't multipart/form-data exactly as unsafe as application/xml? For instance I would expect cross-origin POST requests to the url bank/money-orders/ to always be disallowed, regardless of the content type the endpoint accepts.
推荐答案由于:在甚至没有想到CORS之前，就有可能仅通过例如从一个来源发送的网页发送跨域POST请求.用户将结果填写到另一个来源的页面上，然后单击 Submit 按钮将其发送到另一个来源.
Because: Before CORS was ever even conceived of, it was possible to send a cross-origin POST request just by, e.g., a Web page from one origin sending to another origin the results from a user filling out a form on page at one origin and clicking a Submit button to send it to another origin.
因此，从根本上说，CORS不会改变这种行为-它不会阻止或禁止这种行为，因为在CORS出现之前已经可以并且允许这样做.
So, basically, CORS doesn’t change that behavior—it doesn’t prevent it or disallow it, because it was already possible and allowed before CORS came along.
但是，当时还没有办法在这样的POST请求中发送自定义标头.但是CORS可以做到这一点-提出服务器以前从未见过或必须处理的新请求.因此，预检的目的是要基本上对服务器说，这是一种新的POST(或GET)类型，您必须表明自己选择加入并单击(或使用新方法).
Back then though, there was no way to send custom headers in such a POST request. But CORS makes it possible to do that—to make a new kind of request that servers hadn’t previously seen or had to deal with. So, the purpose of the preflight is to basically say to the server, here’s this new type of POST (or GET) that you must indicate you’re opting-in for and OK with (or new method).
但是，如果POST请求与基本上已经在Web上允许的简单POST请求的类型没有任何不同，则不必直接前往服务器.
But that heads-up to the server is not necessary if the POST request is not any different from the kind of simple POST requests that have basically always been allowed on the Web already.
更多推荐
为什么POST请求不总是预检?
发布评论