Chrome saying No 'Access-Control-Allow-Origin' header, but the header is there

Question

This issue is mentioned in stackoverflow a dozen times already, but I have a different issue.

Chrome first makes an "OPTIONS" call to get the headers. As you can see, the correct headers are there.

For some reason, Chrome doesn't notice the header and cancels the actual request in the same manner that it would if the header wasn't there at all.

The page actually makes three calls and curiously, one of them works.

So the question is, when the header really is there, why does Chrome not respect it? What could I do to debug it?

Update

I tried adding Access-Control-Allow-Methods so now the header response from the OPTIONS call includes these response headers:

Access-Control-Allow-Headers:Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods:POST, GET, OPTIONS
Access-Control-Allow-Origin:*

The result is the same.

Setting the headers on the server side

I set the headers on the serverside on every request (in Global.asax.cs Application_BeginRequest)

Response.Headers.Add("Access-Control-Allow-Origin", "*");
Response.Headers.Add("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
Response.Headers.Add("Access-Control-Allow-Methods", "POST, GET, OPTIONS");

After investigating with Fiddler

I looked through the raw request and response and found something surprising: The error is a simple HTTP 500 error from the application. Likely because the HTTP 500 error does not contain the right headers, Chrome doesn't show the returned error but instead shows the header related error.

Answer

So in conclusion, if Chrome gives says No 'Access-Control-Allow-Origin' header it might actually cover up a HTTP 500 error. This can be determined by checking request and response in Fiddler.

Answer 1

If Chrome says No 'Access-Control-Allow-Origin' header it might actually cover up a HTTP 500 error. This can be determined by checking request and response in Fiddler.