CORS or Cross Origin Resource Sharing is an http mechanism to let a user gain access to resources located on a domain other that the one the site lives on by using some additional headers. So for example lets say your app located on
http://test1.domain.com needs to make a REST call to an api located on
Now By default a browser wouldn’t allow such a request. This is done for http security reasons. What that means is a browser wouldn’t allow a request made from within a script on a webpage to access any HTTP resources located on a domain other than the one site was originally loaded from. For example both XMLHttpRequest and the Fetch API follow same-origin policy. Thats where CORS comes in. CORS facilitates this behavior by first validating
test2.domain.com using some special headers
The headers that relate to CORS are :
The way CORS works is :
- Browser encounters an resquest being made to test2.domain.com.
- It examines if the request is GET or HEAD. If it is, it looks for any custom HTTP Headers. If it finds any, it moves on to step 3 otherwise it proceeds to make the actual request, i.e step 7.
- Browser then makes an OPTIONS request
test2.domain.comusing following headers, Origin, Access-Control-Request-Method and Access-Control-Request Headers.
test2.domain.commust now respond with appropriate Access-Control headers.
- If appropriate Access-Control- headers are not found in the response of the OPTIONS request, flow terminates with an error.
- If appropriate Access-Control-* headers are found in the response of the OPTIONS request, proceed to step 7.
- Make the actual request.
test2.domain.com, is an api gateway, we can make it CORS Compatible by simply enabling CORS options in gateway settings. However if you find yourself in a situation where the domain or even gateway doesn’t supports this functionality out of box, don’t worry, there’s still a way.
You can have a iRule setup in F5 to insert these custom headers to make
test2.domain.com, CORS Compatible
I found a really interesting case, while working with CORS, which I think might be worth mentioning here. The setup was something like this, I had a site hosted at
domain_a. It needed a resource hosted at
domain_b being an API gateway, I enabled out-of-box CORS functionality on gateway and thought that was it. What I found was that all calls being made to gateway were going through except one particular call which was a resource on a application hosted on websphere server behind gateway. That call was always erroring out with same old CORS error :
No 'Access-Control-Allow-Origin' header is present on the request resource. Origin 'http://test1.domain.com' is therefore not allowed access.
On looking more closely, what was found that
Access-Control-* headers were missing from response coming back for that resource. Now Websphere comes with its own http server, and turns out that http server was eating up the access control headers. From there it was an easy fix to just fix the http.conf on websphere.
So always make sure to validate if you have any underlying http/web server in your infrastructure, if you ever run into something like this.
I am a Devops Expert and Machine Learning enthusiast. Please find my original blog post at An Average Joe