4

I've been trying to make a simple iron-ajax post to the server, but it keeps failing at the preflight call. For the life of me I can't figure out what's going on, all the CORS headers seem to be correct on the server.

Response headers

Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:Content-Type
Access-Control-Allow-Methods:GET, POST, PUT, OPTIONS
Access-Control-Allow-Origin:*
cache-control:must-revalidate, private, no-cache, no-store, max-age=0
Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:138
Content-Type:text/html

Request headers

Accept:*/*
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:en-US,en;q=0.8
Access-Control-Request-Headers:content-type
Access-Control-Request-Method:POST
Cache-Control:no-cache
Connection:keep-alive

The request is indeed made from localhost, but I would have thought that the * should take care of that.

Errors that are showing up in the console are: OPTIONS https://... 403 (Forbidden) and 

XMLHttpRequest cannot load https://.... Response for preflight has invalid HTTP status code 403

Any help/advice is appreciated.

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
DVM
  • 1,229
  • 3
  • 16
  • 22
  • What’s the exact error message you’re seeing in your browser devtools console? Consider editing/updating your question to include that information – sideshowbarker Jul 07 '17 at 09:49
  • `OPTIONS https://... 403 (Forbidden)` and `XMLHttpRequest cannot load https://.... Response for preflight has invalid HTTP status code 403` – DVM Jul 07 '17 at 09:51
  • 1
    So yeah that indicates a general problem with the server backend not being configured to handle OPTIONS requests, not just preflight OPTIONS requests. The server needs to respond to OPTIONS requests with a 2xx—200 or 204. If it doesn’t, then it makes no difference what Access-Control-\* headers you have it configured to send. And the answer to configuring the server to handle OPTIONS requests in the right way—to send a 200 or 204 success message—depends on what server software it’s running – sideshowbarker Jul 07 '17 at 09:55

1 Answers1

5

The 403 response status indicates a general problem with the server backend not being configured to handle OPTIONS requests, not just CORS preflight OPTIONS requests.

The server must respond to OPTIONS requests with a 2xx success status—typically 200 or 204.

If the server doesn’t do that, it makes no difference what Access-Control-* headers you have it configured to send. And the answer to configuring it to handle OPTIONS requests in the right way — to send a 200 or 204 success message — depends on what server software it’s running.

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
  • One more question: just tried the same call with Postman and that worked fine. Does that mean that it might be a different issue? – DVM Jul 07 '17 at 10:15
  • 2
    If you mean the response to the POST request worked fine in Postman, that’s expected, because Postman doesn’t make a preflight OPTIONS request before trying the POST request—because only browsers make the preflight OPTIONS request, and only for requests made by XHR/Fetch/Ajax calls from frontend JavaScript code running in a browser at a specific origin (which Postman is not). But if you’re instead saying you tried making the OPTIONS request in Postman and didn’t get a 403, then yeah that would indicate a different problem – sideshowbarker Jul 07 '17 at 17:19
  • @sideshowbarker I need wildfly17 to be configured to handle OPTIONS requests as I too am getting 403 back. I looked around but couldn't find an answer. Can you help me to find good documentation about configuring Wildfly17? – oxyt Sep 26 '19 at 16:04