Introduction
If you’ve just started out on setting up web servers with HTTP requests, I welcome you to the intricate world of CORS. If you don’t know already, CORS is short for “Cross-Origin Resource Sharing”. So what’s the fuss all about?
To put it as simply as possible, CORS is a way to access data (or resources) from another website, then the one you’re setting the request from, by means of sending HTTP requests and receiving HTTP responses by the client (browser) from the server. Most of you are quite familiar with these terms and their uses. But there’s a need for you to understand certain aspects of CORS without which, you’d be unable to surpass the following error message:
“response for preflight is invalid (redirect)”The aim of this article would be to walk you through the reasoning of this error message, as well as to provide you with the possible fixes you can try out for yourself to surpass the message.
Why is a preflight request required to be sent?
Before we move on to the actual reasoning, you should keep note of a few things. A preflight request is sent to the server, if your HTTP request meets at least one, or all of the following criterias:
- The request method is not among the commonly used ones (e.g. GET, POST, HEAD)
- If the Content-type header of the request is anything else than:
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain
- If you used a custom header other than the ones that are sent automatically by the user agent.
Keeping the above in mind, you’d get a better understanding as to why you see the error in the first place. Now moving on to the actual palaver.
Why do I see “response for preflight is invalid (redirect)”?
Let’s get down to some basic business. It’s important to know that a preflight is not mandated if your request is a simple one, that is, it does not meet any of the criterias mentioned in the previous section. So if your request doesn’t necessarily need anything more than the bare defaults, then you should probably consider fixing your code to exclude anything extra.
The reason why you see this error message is not that complicated if you understand the fundamentals of HTTP requests. When a preflight HTTP request is sent to the target server, the path to the resource you’re requesting for is provided. If for some reason, the path to that resource has changed, or has moved to another location, then you’d receive any of the 300 status codes. This code is sent by the CORS server when it is unable to find the resource you’re requesting for, and will return a response which is supposed to redirect you to the new path instead.
Now here’s the catch. For simple requests that don’t require a preflight, the redirection invoked by the response from the CORS server will automatically send you to the redirected page or path. But such a thing will not apply to a preflight request. This is because a preflight request cannot accept a redirection response from a server.
The problem is further escalated given that vanilla Javascript code will not show you the exact reasoning nor the new path of the file. So how do you go about fixing the error?
How to fix “response for preflight is invalid (redirect)”
Add or remove a forward-slash at the end
A very common way for people to use the wrong path when sending the HTTP request is to include, or not include the forward-slash at the very end of the URL. You may think it is not that crucial, but it is very, very crucial. Let me tell you how.
Traditionally, web servers used to recognise the end of a URL based on whether you add a forward slash or not. If you add the forward slash, then the last path would be considered as a folder. Take a look at this:
https://example.com/somefolder/Here, ‘somefolder’ is considered as a folder, as you added the forward-slash at the end of the URL. If it was a file instead of a folder, such as:
https://example.com/somefile/and you still add a forward slash at the end, then the file would be considered as a folder, which is not the case. For this reason, you may get anything from a 404 not found to 301 Moved Permanently status code as a response. So in order to fix that, simply remove the forward slash at the end:
https://example.com/somefileNot adding a forward-slash at the end means that the last word is treated as a file, instead of a folder.
So when sending the HTTP request, if the target resource you’re requesting for is a file and not a folder, then make sure to remove the forward slash at the end when you initiate the URL. If your target resource is a folder instead, then make sure to rather add a forward slash in the end.
Change ‘http’ to ‘https’
Another common reason for getting a redirection response from the CORS server is because you used http instead of https, if the server is already using https. However, this does not apply if your target is using a modern web server like Apache, which will automatically redirect a http URL into a https one.
If the target server is incapable of automatically redirecting to an https URL, then you’re sure to get the redirection response. In this case, simply changing:
http://example.com/somefolder/to:
https://example.com/somefolder/Should no longer give you a redirection error, if that’s the real culprit here. But the question is, how do you figure out if this actually is the case, as Javascript doesn’t return to you the location? TO do this, we’d use a command line tool called curl in Linux.
To give you a simple demonstration of the above situation of http and https, consider a URL to a GitHub repository. If I type out the following command in a Linux terminal:
curl -X OPTION http://github.com/Droid-Potato/termux-setup.gitThis is the output that I get:
If you pay close attention, you’d see the words “Moved Permanently”, with a status code of 301. This tells us that using http will return us a redirection response, with an additional header at the end, which is the Location header. This tells us about the new path where our target resource has been relocated. The Location header tells us that the new path would be:
https://github.com/Droid-Potato/termux-setup.gitI could probably be no clearer than this.
Use the new path/location suggested by HTTP response
This is the last possible reason for the redirection response. That is, the URL to the target resource has been moved to a whole different path or URL, where only the https or forward-slash do not solely apply. You might need to change the whole URL in the HTTP request code you created into the new path that the Location header of the response indicates.
To do this, simply use the curl command with the initial URL you were trying to use, as then you’d get a response from the terminal with the new location. For example, if your URL initially was something like “https://example.org/somedata”, you’d first use the following syntax to get an output of the HTTP response along with the new path, which is defined by the location header:
curl -X OPTION https://example.org/somedata -iReplace that demo URL with your actual URL. You should get an output that should be similar to the following:
HTTP/1.1 3XX XXXXX XXXXX
Content-Length: XXXX
Location: https://example.com/path/to/new/location/of/dataWhat you need to focus on in the above output is the Location Header. Extract this information, and use this new URL you found into your actual code.
Wala! The next time you send an HTTP request for CORS, you should no longer see that error.
Conclusion
Before you leave, you might as well take away the key points from this article. First, the preflight request is only sent as long as you don’t need a different request method or a custom header along with a media type not included in the default content-type header. Second, if your target resource is a folder, use a forward slash, and if it’s a file, omit the slash. Third, make sure to use https instead of http, and if you’re unsure, use the curl command. And lastly, if your target resource has been wholly moved to a different URL, then once again use the curl command to figure out the new path by examining the location header, and incorporating it in your HTTP request code.
Have a very good day!
