Sometimes I really miss the times when everything was so simple, even though lots of things seems to be really easy today. I remember the days we had only HTML, no backend/frontend separation, no frameworks, no CSS*, nothing. So let’s talk about browser-level cross-origin HTTP requests performing some kind of pre-CORS ‘sanity check’ using
options method that allow us to e.g. fetch the JSON data from remote API for our node-powered Ember SPA. To be more clear, we’ll take a look on a CORS preflight requests :)
What is CORS?
There are tons of resources about CORS, so if you hear about it for the first time I recommend you to visit this link if you want to dive deeper. If you don’t know what is CORS and don’t want to dive deeper, you’re probably not interested in further reading of this post ;-)
I found the best description of CORS preflight requests on the MDN CORS page
Preflighted requests first send an HTTP request by the OPTIONS method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data.
Great explanation, if we’re safe with our request, no preflight needed. Easy.
When a preflight request is performed?
We’re running a preflight request if used HTTP verb is other than
POST or the request headers are not, let’s say, safe ones or the content-type is other than
We assume it’s safe to process the requests matching all above criteria and thus we’re not preflighting it. It’s quite clear that such requests will not change any crucial app data. But if any of conditions above is violated, the preflight request is performed.
Why do we need preflights?
When the preflight request is not successful, we will not be able to send the real request. Let me quote here the easiest explanation I’ve ever seen. Why do we need CORS preflight? According to w3.org
To protect resources against cross-origin requests that could not originate from certain user agents before this specification existed a preflight request is made to ensure that the resource is aware of this specification.
Easy, huh? :-D
Don’t worry, I bet there are only 4 people in the world that understand this sentence after reading it only once. What I think the preflight was introduced is that it integrates the modern web with all the pre-CORS resources that were possibly in danger of receiving unexpected requests. The web is evolving, but not all the resources are maintained properly and to make sure everybody are as safe as possible, we’re linking the ancient** and modern web standards with CORS preflight.
The conclusion is that whether you want it or not, you’re probably using CORS preflighted requests everyday so it’s good to know what’s going on under the hood and why. I’ll try to write down some more practical stuff on this topic later, hopefully you’ll find it useful or at least a little interesting :-)
Thanks for reading and feel free to share your thoughts!
* - okay, I’ve done my first simple website actually using CSS, but believe me it was a new technology!
** - everything what could possibly happen in the previous millennium is ancient ;-)