3

So I'm trying to make a cross-domain AJAX request with javascript.

My OPTIONS request is executing without any problems, and I'm getting back Access-Control-Allow-Origin:* as a response header. However, when trying to make the subsequent POST request, I get the following error:

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://phoenix-client.local' is therefore not allowed access.

I've verified multiple times that my OPTIONS request is indeed sending the correct response, including the Access-Control-Allow-Origin header, but the browser seems to ignore it :(

Any ideas?

edit - A couple things I've been noticing:

If I try to update the headers my server is sending, everyone else except me gets the newly updated headers when they make a request. It's as if my computer is caching the responses to OPTIONS requests.

This is only occurring for one of my AJAX requests. I make multiple requests before the request that fails, and all of them work fine (with the headers as is) except for the last one.

EDIT!!!!

Updating this post (extremely late). This ended up not being a CORS error. I get a false "Access-Control-Allow-Origin" error from Chrome, but when I run the AJAX request directly, I get the real error (which typically is supposed to be an error 500, with some sort of PHP error messaging). Still unsure why this is occurring though...

robert.bo.roth
  • 1,343
  • 3
  • 14
  • 24
  • 4
    Is the `POST` request *also* sending `Access-Control-Allow-Origin`? – Explosion Pills Nov 27 '13 at 16:41
  • No, it's not sending Access-Control-Allow-Origin. Just started having this problem on a single computer (mine). Works for other developers, even when accessing my local server remotely using the internal IP address – robert.bo.roth Nov 27 '13 at 17:17
  • Your POST must also send Access-Control-Allow-Origin, as @ExplosionPills inferred. – Ray Nicholus Nov 27 '13 at 17:26
  • Since when? And why do other computers making the same call not have to send that header? The bigger issue at hand is that when I'm updating my server response code, to send different response headers (like sending the exact origin rather than the wildcard '*'), I'm still getting the same headers back. It's almost as if my computer has cached the OPTIONS response and isn't using the real data I'm sending from my local server. I've had other developers try the same request from their computers, directed at my local network IP, and they get the correct headers and their requests don't fail. – robert.bo.roth Nov 27 '13 at 17:32
  • I can't even send with the Access-Control-Allow-Origin header on my POST request because the browser isn't getting the correct `Access-Control-Allow-Headers` after I've added allow-origin to the allowed headers. – robert.bo.roth Nov 27 '13 at 17:33
  • Your statements here aren't really making much sense. I suggest you read up on CORS as you seem to have some gaps in your knowledge. You don't need to include CORS headers in your Access-Control-Allow-Headers header, for example. Also, as to your "since when" comment: Since always. Read the spec: http://www.w3.org/TR/cors/ – Ray Nicholus Nov 27 '13 at 17:36
  • This problem doesn't really make much sense. I understand CORS, and I've had my server setup and running fine for months as is without any issues. Our current development, staging, and live servers are working right now, with the same code and server setup that I have. I have 3 other developers who have the same setup, and theirs is working fine. My local environment is the ONLY one that has this issue, and I guarantee you it has nothing to do with my understanding of CORS. – robert.bo.roth Nov 27 '13 at 17:39
  • Was the request failing on the OPTIONS (preflight) or the underlying POST? The symptoms described in your edit suggests that the failure was on the preflight. – Ray Nicholus Apr 02 '14 at 18:29
  • The request fails on the POST, but Chrome keeps telling me the error is on the preflight request. It says that the OPTIONS request doesn't return any Access-Control-Allow-Origin header, but I'm most definitely sending the wildcard (*) for Access-Control-Allow-Origin. It seems to be a bug with how Chrome is reporting errors of this nature (or perhaps our Symfony2 install is doing something strange with its error responses), because when I run the EXACT same request from a third-party app for testing API requests, I get the real server error, with the php stacktrace and everything on the POST. – robert.bo.roth Apr 02 '14 at 19:47
  • What if you make an OPTIONS request with an Origin header from your third-party API app? If the error really is on the OPTIONS, then Chrome is following the spec correctly. – Ray Nicholus Apr 02 '14 at 19:54
  • No, there's no error on the OPTIONS request. Even in the Chrome Developer Tools Network tab, it shows that it's received the proper headers from the OPTIONS request, I see my wildcard flag, but it fails to give me the proper error that should be on the following POST request. My entire API works. If I introduce an error onto a single POST route, for example, that route will seem like it fails on the OPTIONS request, when in reality the error is coming from PHP during the POST request. – robert.bo.roth Apr 02 '14 at 19:56
  • Additionally, the error in chrome suggests that I'm not sending back ANY Access-Control-Allow-Origin, not just that the domain I'm sending the request from doesn't have access. If I forcefully change the response of my OPTIONS request to send the wrong domain back, then I do indeed get the correct error on the OPTIONS request, telling me that my domain doesn't have access to this route (because the server sent back a different domain for the Allow-Origin header) – robert.bo.roth Apr 02 '14 at 19:59
  • The spec outlines very specific behavior for network errors in the context of CORS requests. For preflighted requests, a network error or non 2xx response will be reported as a CORS error, even if the ACAO header is correct. For the underlying request, the specific error should be visible though, per my understanding of the spec. Does the same thing happen in Firefox? – Ray Nicholus Apr 02 '14 at 20:09
  • That's what I was expecting. We're not sending with response 2xx, but it should have been giving us some sort of indication that it wasn't actually an Access-Control error, or at least I'd thought so. Firefox gives me an error on either OPTIONS or POST, depending on the nature of the PHP error. If it's something that prevents an entire script from loading, I get the OPTIONS error (that seems correct), but when I do something like reference an undefined function from within a function that runs when the POST is executed, I get a 500 error on the POST request, as expected. – robert.bo.roth Apr 02 '14 at 20:21
  • For example, I just got this error from Chrome (on the OPTIONS request): `XMLHttpRequest cannot load http://phoenix/api/organizations/11. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://phoenix-client.local' is therefore not allowed access.`, but this error from Firefox (on the POST) `"NetworkError: 500 Internal Server Error - http://phoenix/api/organizations/11"` – robert.bo.roth Apr 02 '14 at 20:22
  • Looks like this is a reported bug in Chrome: https://code.google.com/p/chromium/issues/detail?id=269192 – Ray Nicholus Apr 02 '14 at 20:30
  • Ah, nice. Thanks for the link, and the discussion :) – robert.bo.roth Apr 02 '14 at 20:40

1 Answers1

4

In case others run into this issue, I'll combine some of my comments above.

The spec outlines very specific behavior for network errors in the context of CORS requests. For preflighted requests, a network error or non 2xx response will be reported as a CORS error, even if the ACAO header is correct. For the underlying request, the specific error should be visible though, per my understanding of the spec. That said, Chrome appears to be displaying a CORS error on the underlying request with a non 2xx. Looks like this is a reported bug in Chrome: http://code.google.com/p/chromium/issues/detail?id=269192.

Ray Nicholus
  • 19,538
  • 14
  • 59
  • 82
  • Ran into this too. In short, if you're suddenly getting this error, and are pretty sure your CORS was working fine, check for 500s or other problems in your server response. Chrome is misreporting. – skoczen Dec 18 '15 at 16:32