There is a general agreement among the browsers regarding simple requests. These requests are considered safe. For example, GET, HEAD, and POST are considered simple requests. There are some restrictions on media types that are allowed through these requests. Headers such as Accept, Accept-Language, Content-Type, and a few more are considered white-listed.
Simple requests are considered safe.
For complete and detailed information on safe and un-safe requests, and for preflight requests, please refer to the documentation on the Mozilla website - https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
Video Explanation (see it happen!)
Please watch the following youtube video:
A cross-origin request that doesn't meet the requirements of a simple request is momentarily put on hold because it could have implications for user data. The browser first secretly queries the server if it is safe to send that request. It makes a preflight request. A preflight request is a peek into the willingness of the server.
The browser sends an HTTP OPTIONS request containing up to two headers. It sends an Access-Control-Request-Method header with its value set to the type of request to make. It can also add an Access-Control-Request-Headers header with its value set equal to the list of headers to be sent.
Let's take an example. Suppose a browser has to make a cross-origin request of the HTTP PUT type containing a custom header X-My-Header. In this case, a preflight HTTP OPTIONS request with Access-Control-Request-Method = PUT and Access-Control-Request-Headers = X-My-Header would be sent by the browser.
Server Response to a Preflight Request
If the server application is configured to accept cross-origin requests of the PUT type, then it responds with a 204 No Content response containing a header called Access-Control-Allow-Methods, and echoes back the comma-separated list of allowed methods. Similarly, if it can accept the headers, then the response also contains Access-Control-Allow-Headers with its value set equal to the comma-separated list of headers.
If the headers are present in the response, then the browser makes the actual cross-origin request and sends the payload. If the response doesn't contain those headers then the browser doesn't make that request.
A server can also add a Access-Control-Max-Age header for the browser to determine the duration for which it can cache the response without sending the next pre-flight request.
With this primer, we are now ready to examine the C# ASPNET Core code. We shall take it up in the next tutorial. Thanks!
This Blog Post/Article "(CORS C# ASP.NET Core) Primer on CORS Preflight Requests" by Parveen is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.