CODEWITHSUNDEEP
corspreflight
n179911
n179911

Reputation: 20291

How to resolve 'preflight is invalid (redirect)' or 'redirect is not allowed for a preflight request'

I have followed this step to setup my server to enable CORS. https://learn.microsoft.com/en-us/aspnet/web-api/overview/security/enabling-cross-origin-requests-in-web-api

But now in my browser dev console, I see this error message:

XMLHttpRequest cannot load https://serveraddress/abc. Response for preflight is invalid (redirect)

Do you know what can I do to fix it? I am making a CORS request in HTTPS. I think that is causing the 'preflight is invalid (redirect)' failure. But I don't know why or what is redirecting the OPTIONS request.

Thank you.

Upvotes: 90

Views: 208745

Answers (6)

Нигилист Джордан
Нигилист Джордан

Reputation: 185

First of all, ensure that you have "Access-Control-Allow-Origin": "*" in the headers

then just remove "/" at the end of url

e.g. change

url: "https://facebook/api/login/"

into

url: "https://facebook/api/login" (without '/')

or vice versa

Upvotes: 15

sideshowbarker
sideshowbarker

Reputation: 87984

Short answer: Ensure the request URL in your code isn’t missing a trailing slash.

A missing-trailing-slash problem is the most-common cause of the error cited in the question.

But that’s not the only cause — just the most common. Read on for more details.

When you see this error, it means your code is triggering your browser to send a CORS preflight OPTIONS request, and the server’s responding with a 3xx redirect. To avoid the error, your request needs to get a 2xx success response instead.

You may be able to adjust your code to avoid triggering browsers to send the OPTIONS request.

As far as what all’s going on in this case, it’s important to know browsers do a CORS preflight if:

  • the request method is anything other than GET, HEAD, or POST
  • you’ve set custom request headers other than Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, or Width
  • the Content-Type request header has a value other than application/x-www-form-urlencoded, multipart/form-data, or text/plain

If you can’t change your code to avoid need for browsers to do a preflight, another option is:

  1. Check the URL in the Location response header in the response to the OPTIONS request.
  2. Change your code to make the request to that other URL directly instead.

The difference between the URLs might be something as simple as a trailing slash in the path — for example, you may need to change the URL in your code to add a trailing slash — e.g., http://localhost/api/auth/login/ (notice the trailing slash) rather than http://localhost/api/auth/login (no trailing slash) — or you might instead need to remove a trailing slash.

You can use the Network pane in browser devtools to examine the response to the OPTIONS request and to find the redirect URL in the value of the Location response header.

However, in some cases, all of the following will be true:

  • you’re not able to avoid the preflight OPTIONS
  • you’re not able to make any adjustments to the request URL
  • you’re not able to replace the request URL with a completely different URL

A common case with those conditions is when you try to work with some 3rd-party endpoint that requires an OAuth or SSO workflow that’s not intended to be used from frontend code.

In such cases — in all cases, actually — what’s essential to realize is that the response to the preflight must come from the same origin to which your frontend code sent the request.

So even if you create a server-side proxy that you control:

  1. If your browser sends a preflight OPTIONS request to your proxy.
  2. You’ve configured the proxy such that it just redirects the request to a 3rd-party endpoint.
  3. Thus, your frontend ends up receiving a response directly from that 3rd-party endpoint.

…then the preflight will fail.

In such a case ultimately your only alternative is: ensure the preflight isn’t just redirected to the 3rd-party endpoint but instead your own server-side (proxy) code receives the response from that endpoint, consumes it, and then sends a response of its own back to your frontend code.

Upvotes: 202

Ian Michael
Ian Michael

Reputation: 1

The CORS request was responded to by the server with an HTTP redirect to a URL on a different origin than the original request, which is not permitted during CORS requests.

For example, if the page https://service.tld/fetchdata were requested, and the HTTP response is "301 Moved Permanently", "307 Temporary Redirect", or "308 Permanent Redirect" with a Location of https://anotherservice.net/getdata, the CORS request will fail in this manner.

To fix the problem, update your code to use the new URL as reported by the redirect, thereby avoiding the redirect.The CORS request was responded to by the server with an HTTP redirect to a URL on a different origin than the original request, which is not permitted during CORS requests.

For example, if the page https://service.tld/fetchdata were requested, and the HTTP response is "301 Moved Permanently", "307 Temporary Redirect", or "308 Permanent Redirect" with a Location of https://anotherservice.net/getdata, the CORS request will fail in this manner.

To fix the problem, update your code to use the new URL as reported by the redirect, thereby avoiding the redirect.

Upvotes: -1

Saurabh
Saurabh

Reputation: 19

in my case i also solve this preflight request by just putting one slash (/) at the end of the api

#django #reactJs

Upvotes: 1

mAsK
mAsK

Reputation: 309

In my case I did not have to set the request header to have "Access-Control-Allow-Origin": "*". The url HAD TO be ending with a "/" at the end

Upvotes: 5

Adeojo Emmanuel IMM
Adeojo Emmanuel IMM

Reputation: 2154

This happens sometimes when you try calling an https service as http, for example when you perform a request on:

'http://example.com/api/v2/tickets'

Which should be:

'https://example.com/api/v2/tickets'

Upvotes: 44

Related Questions