Response for preflight 403 forbidden

Question

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.

Cancer

What’s the exact error message you’re seeing in your browser devtools console? Consider editing/updating your question to include that information – Assamese

OPTIONS https://... 403 (Forbidden) and XMLHttpRequest cannot load https://.... Response for preflight has invalid HTTP status code 403 – Cancer

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 – Assamese

Answer 1

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.

Assamese

One more question: just tried the same call with Postman and that worked fine. Does that mean that it might be a different issue? – Cancer

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 – Assamese

@Assamese 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? – Mozellemozes