We are implementing short URLs to redirect on our project.
I do an API request to my server using axios, with the info on the short url.
The server responds with a redirect status 308 succesffuly.
I see in the response headers, the location parameter (to redirect to) is correct.
And we have also set Access-Control-Allow-Origin: *
But the redirect does not follow through...
After recieving the 308; the browser attempts a preflight OPTIONS request to the redirect URL, followed by a GET request to the redirect URL.
Both of these return an error.
The preflight request error: CORS Misssing Allow Origin. And the GET request gives error: NS_ERROR_DOM_BAD_URI
Not sure what the issue is. Is it on the front-end, or on the server-side?
Any advice would be greatly appreciated!
Related
Firebase fails to redirect any HTTP POST requests to HTTPS POST. EX:
POST / HTTP/1.1
Host: apis.mydomain.com
is redirected by Firebase NGINX to
GET / HTTP/1.1
Host: apis.mydomain.com
if you are explicit about https, then NGINX works properly: POST -> POST
So, when the request hits Firebase hosting, and redirects your request to a firebase function that can be accessed by an https endpoint, the method has the possibility of collapsing into a GET from a POST method.
Looking closer at the headers, inside the Firebase Cloud Function, the protocol always expresses as http, instead of https.
I'm assuming this is an internal issue that I cannot modify, however, this is an issue for what I am doing, and this definitely is a problem given I cannot modify the NGINX that is handling my http(s) requests.
If you redirect with a 301 or 302 status code, the POST is downgraded to GET.
You need to use a 307 status to maintain POST across the redirect. See this document for details.
On Nginx, you will need to use a return statement. For example:
return 307 https://$host$request_uri;
What type of redirect should I be using to redirect a user to a connection page if he needs to be authenticated before using one service of my website ?
Just to be sure using the right numbers for the crawler's to witness what a good student I am !
Available redirection statuses:
301 Moved Permanently
The 301 (Moved Permanently) status code indicates that the target
resource has been assigned a new permanent URI.
302 Found
The 302 (Found) status code indicates that the target resource resides
temporarily under a different URI.
303 See Other
The 303 (See Other) status code indicates that the server is
redirecting the user agent to a different resource.
304 Not Modified
There is no need for the server to transfer a representation of the
target resource because the request indicates that the client already
has a valid representation.
307 Temporary Redirect
This status code is similar to 302 (Found), except that it does not
allow changing the request method from POST to GET.
308 Permanent Redirect
This status code is similar to 301 (Moved Permanently), except that it
does not allow changing the request method from POST to GET.
Statuses 305 Use Proxy and 306 (Unused) are respectively deprecated and no longer used.
So by default, I would choose the 303 See Other, since it's the one that suits your needs the best.
You should not redirect a user if he need to be logged in to view an URL.
This URL should shoot a 401 status with a form to let your user log in directly. And then return him the content with an HTTP 200 on the same URL.
Some information on 401 from HTTP specifications:
401 Unauthorized
The request requires user authentication. The
response MUST include a WWW-Authenticate header field (section 14.47)
containing a challenge applicable to the requested resource. The
client MAY repeat the request with a suitable Authorization header
field (section 14.8). If the request already included Authorization
credentials, then the 401 response indicates that authorization has
been refused for those credentials. If the 401 response contains the
same challenge as the prior response, and the user agent has already
attempted authentication at least once, then the user SHOULD be
presented the entity that was given in the response, since that entity
might include relevant diagnostic information. HTTP access
authentication is explained in "HTTP Authentication: Basic and Digest
Access Authentication" [43].
I have read through some relevant portions of the HTTP 1.0 and HTTP 1.1 specifications to try to ascertain whether all HTTP clients will perform the appropriate redirect when they receive a response of a 301 or 302 to a GET request.
Are there any HTTP clients that do not automatically follow the returned redirect in such an instance?
Why do you want to know this? What are you going to do with the answer, not using redirects if so?
The specs quite clearly state:
6.4. Redirection 3xx
The 3xx (Redirection) class of status code indicates that further
action needs to be taken by the user agent in order to fulfill the
request. If a Location header field (Section 7.1.2) is provided, the
user agent MAY automatically redirect its request to the URI
referenced by the Location field value, even if the specific status
code is not understood.
So no, a client that does not automatically redirects, still adheres to the specs.
I'm building a test tool with Go. This tool can retrieve a specific URL by doing a POST request to an endpoint which returns a 303 with the Location to test. Sometimes this location itself is redirected with a 301 which I want to follow as well.
Test tool -> POST /get-url-to-test -> 303 Location: /other -> GET /other -> 301 Location: /new-other (stops here because initial request is POST)
As we can see in Go's source (lines 241 to 257), it seems like GET requests follow 301 redirects, but not POST requests:
http://golang.org/src/net/http/client.go
Why is that? Is that part of an HTTP spec? Is this an decision that was made by the Go community?
The reason I'm asking is because in my case, I'd have to manually do a new GET request to get to the URL redirected to by /other, I think.
EDIT 1: I made a mistake before: the /other resource is being fetched by Go with a GET request. But since it returns a 301 and the initial request was a POST, Go stops redirecting on the 301. That seems odd. Am I missing something?
EDIT 2: This may be a bug, I've opened an issue on Github: https://github.com/golang/go/issues/9348
The HTTP RFC 2616 says:
10.3 Redirection 3xx
This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent
without interaction with the user if and only if the method used in
the second request is GET or HEAD.
In web.config of my ASP.NET website I have customErrors turned on and set to redirect to a specific action in case of HTTP 404:
now I start Fiddler and in my browser query some URL that yields HTTP 404. Fiddler clearly shows that first the browser queries that URL and gets HTTP 302 with the path to <...>/Error/FileNotFound and queries that and finally receives HTTP 200.
So effectively the original HTTP 404 disappears and I get HTTP 302 followed by HTTP 200.
Meanwhile if I query some invalid address from StackOverflow (like https://stackoverflow.com/ques/ask) I get HTTP 404 in a single request. I mention this because StackOverflow uses ASP.NET too.
How do I use customErrors in IIS to get HTTP 404 instead of HTTP 302 followed by HTTP 200?
In the customErrors node you can set the following attribute:
redirectMode="ResponseRewrite"
This will prevent the page from redirecting and will instead write the error page instead of the one requested.
NB: You will also have to ensure that the page being used as the 404 error page actually itself returns a 404 status code in codebehind; the MS rewrite support doesn't automatically pass the status code through, see link:
https://connect.microsoft.com/VisualStudio/feedback/details/507171/asp-net-returns-incorrect-status-code-even-with-redirectmode-responserewrite