Your firewall can cause CORS preflight to fail.
I can’t tell you exactly why CORS preflight requests are failing in your case. There are many things you can try, but I will tell you this: if you’ve tried a few things and it won’t work, ask yourself whether you’re behind a firewall controlled by someone else. If you are, read the rest of this post.
There I was, plugging away on an iPad application, everything had been splendid for more than a year. Then I see an error in the console: uh oh. A request to my RESTful API is failing preflight in Chrome. Tried Safari and FireFox. Same.
I tried everything. I set the headers in .htaccess 5 different ways, and then with PHP a few different ways. No matter what, the headers never make it to the client. After 3 hours of swearing and asking God why such awful things happen to good people, I gave up and went home. Got to my desk, plugged in my Mac and then … it worked fine.
The next day I was working on-site again, and I had exactly the same trouble with CORS. My client asked me whether I could tether with my phone to test it that way. I did so, and it worked. The client’s network was the culprit, apparently. So, I spoke with IT. They’d just installed a new firewall, and it was stripping the following from the server’s responses:
Access-Control-Allow-Headers:origin, x-requested-with, content-type Access-Control-Allow-Methods:PUT, GET, POST, DELETE, OPTIONS Access-Control-Allow-Origin:*
Once the issue was understood, it took about 5 minutes for IT to correct it. Back to work.
5 Comments
Why not run TLS? Firewalls can’t tangle with the headers in an TLS connection. In general, why not run TLS always, for everything, for ever?
In real life, people cannot always justify the cost and/or effort. Take this website, for example. I’ll get around to it someday I hope, but there’s hardly a rush.
Second, a client may not see the need for TLS/SSL, and may actually disagree with the political ideas motivating you and I to prefer SSL/TLS at all times. Such clients have paid my bills in the past.
Moreover, when building something new or (esp.) experimental, one does not always start with a ready-to-go domain with installed certificate.
I had the same idea but realized that a user could be behind a corporate firewall that filters encrypted packets by requiring all encryption keys to be managed by an appliance on the LAN ?
So your solution if fine for your own firewall. What do you do if your customers have a similar firewall?
Either switch from CORS to JSONP, or go SSL.