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.
But isn't multipart/form-data exactly as unsafe as application/xml? For instance I would expect cross-origin POST requests to the url http://bank.com/money-orders/ to always be disallowed, regardless of the content type the endpoint accepts.
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.
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.
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).
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.
