Well, this was one of those bugs that took a while to figure out and of course the solution was pretty simple.

It turns out that this:

[EnableCors(origins: “http://MyWebsite.com”, headers: “*”, methods: “*”)]

is not the same as this:

[EnableCors(origins:”http://mywebsite.com”, headers: “*”, methods: “*”)]

I have some JavaScript that calls an ASP.NET web API method on another domain. Let’s pretend that the API is on myservice.com and the website is on mywebsite.com. As you can guess, I was having some issues and getting an error similar to this:

Failed to load http://myservice.com/api/SomeController/SomeMethod: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘http://mywebsite.com is therefore not allowed access.

I tried a lot of things to figure out what was going on. I knew that I had the CORS attribute on my controller and I had config.EnableCors(); set up in my Web API configuration. This is one of the first times I’m using CORS on Azure so I thought it had something to do with Azure, but that was not correct. After trying many, many hacks with no success and staring at my EnableCors Attribute, I had the “crazy” idea to change “http://MyWebsite.com” to ”http://mywebsite.com” and of course, everything worked fine. From now on, I’ll use all lowercase!

I hope you won’t get stuck wasting as much time as I did trying to figure this one out!

3 thoughts on “CORS Origin is Case Sensitive

  1. Hello,
    I run into the same issue on my project. So, the reason, why it is case-sensitive, is a CORS specification:
    6.2 Preflight Request.
    It says: If the value of the Origin header is not a case-sensitive match for any of the values in list of origins do not set any additional headers and terminate this set of steps.
    Regards, Roman

  2. Pingback: Dew Drop - January 5, 2018 (#2637) - Morning Dew

Leave a reply


<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>