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.

Solution

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.

Comments

[monsur]

There should also be an Access-Control-Allow-Methods header. I don't see it in the screenshot.

[Niels Brinch]

The OPTIONS call is supposed to tell the browser that it is OK to go ahead with the real call. If the OPTIONS call fails, it ends up not giving this permission to the browser, which is essentially what the browser is reporting to you.

[Niels Brinch]

Yes very hard to debug. Not sure we can blame Chrome, because it literally does what it should, I guess. But it could be nice if it could share some more details about the failing OPTIONS. Not sure if they already improved this in the meantime actually.