Attempting the following routing with our Azure Front Door:
Assume the Front Door URL is https://foo.azurefd.net, and the backend pool consists of an Azure Web App with URL https://foowebapp.azurewebsites.net.
I have created a routing rule as follows:
User passes POST: https://foo.azurefd.net/api/token/12345
I want that to get directed to POST: https://foowebapp.azurewebsites.net/api/token
I created the rule using Redirect route type. The problem is I get a 405 Method Not Allowed when passing this via the Front Door. If I pass directly to the https://foowebapp.azurewebsites.net/api/token endpoint, I get the expected response.
Why is this happening, and is there another setting in Front Door I need to tweak?
EDIT: I can see now in analyzing the traffic that Front Door is changing the method from POST to GET during the redirect. This is why I'm getting the 405 Method Not Allowed error. But I don't understand why Front Door would change it from a POST to GET. Everything is set to HTTPS only. I have raised this with Azure support but not sure I expect much assistance from them.
Figured it out. By default, Front Door's redirect is set to type 302 (Found). This kind of redirect will always change any non-GET method to a GET. Using either 307 (Temporary Redirect) or 308 (Permanent Redirect) will allow the call to be passed without change the method.
Related
When a client browser receives a 302 response, does the browser modify or ignore any parameters appended to the end of the URL?
For example, I have a server that redirects requests to a different URL but retains any parameters from the original URL and appends to the end of the new redirect URL. However, browser is not including the parameters in the new URL.
For example, if a request comes in to "https://server1.com/path1?filter=value", the redirect server responds with a 302 and "location: https://server2.com/path2?filter=value". But, issue is that the client browser seems to only recognize "https://server2.com/path2".
Should parameter values be tagged a different way in the response?
As noted by Remy Lebeau in the comments to the question, the browser does not modify the location URL in the 302 response. Rather, the issue was caused by the networking in AWS - I was using AWS Lambda to perform the re-direct by reading in the URL on the original request coming in and re-directing according to mapping in the function. First issue was that API gateway was stripping off the query parameters before it was hitting the Lambda function. Second issue was that the function read the "rawPath" attribute from the request, but this does not contain URL query parameters; the query parameters are contained in the "rawQueryString" attribute instead.
I am trying to create a surveymonkey webhook to receive my survey response and i am passing my SugarCRM custom entry point URL as "Subscription Url". But i am getting error " 'mycustomEntryPointUrl' did not return a success status code. Status code is 301". My Entry point is working fine if i run it in browser using its URL also my Sugar is working smoothly.
So, i just want to know any other reason which can cause this error.
Yes so HTTP status code 301 means the page has moved permanently. If you visit it in your browser, for example, you would see a network request to the page specified with a status code of 301, then a second one to the new page. Our API request won't do any redirect, so if a 301 is returned it will raise an error.
This sometimes happens when you go to a page with http and then it redirects to https due to rules on your server.
You also want to make sure your subscription URL supports a HEAD request without any redirect.
I want to 301 redirect the URLs from previous site that are nested, as pencilblue doesn’t support them,
e.g. a/b to page/b
For this I have been experimenting in include/http/request_handler.js but facing some issues.
Call never comes inside RequestHandler.prototype.handleRequest or even RequestHandler.prototype.onSessionRetrieved (seems these methods are not being called from anywhere)
Therefore I placed the code in RequestHandler and after confirming that req is not for public resource or api, I create a new url and execute
return this.doRedirect(newUrl, 301)
This actually works but at the same time I receive
Can’t render headers after they are sent error
#1075 has not helped me much as I’m not sure which specific controller I should modify. I need to catch the req as early as possible and see if it’s a page then redirect to page prefixed url.
Thanks in advance.
There are couple of ways to do redirects. You can do them from a controller or from middleware. You are correct in that, some of the functions in the request handler are not called. These are deprecated despite the fact pencilblue team didn't mark them as such. They replaced a good deal of the request handler functionality with /include/http/router.js and include/http/middleware/index.js. Plugins can register their own middleware to hijack the request pipeline.
See Advanced Routing on wiki for more info about creating your own middleware.
Using the routing framework your plugin would be able to register middleware that would be able to inspect the request and then redirect based on your specific criteria. The Router will be accessible from req.router and from there you could call req.router.redirect (Source).
Reference: #1224
I'm building REST API, and when resource is created normally I return HTTP 201 Created along with Location header to specify where that resource is located. But from some reason http client is not redirecting.
I'm using Postman for this. Does anyone have idea on this problem?
In short, a Location header is not sufficient to trigger a client redirect. It must be used in conjunction with a 3xx HTTP status code.
References:
https://en.m.wikipedia.org/wiki/HTTP_location
Redirecting with a 201 created
This is one of those things where the expectation does not meet what actually happens, and the first thing people think is "well that doesn't work properly", as has been suggested in other comments.
The Location is just a random header, and clients, such as Postman or curl or anything else need to be instructed to follow them. Most won't do this by default, as that is an unreasonable default.
YouTube for example returns a body for some responses and a Location tag too. One example would be video uploads. They respond to your original meta-data for the video is sent with a POST, and they shove a Location URL which is the endpoint to upload the video too. If clients just randomly redirected to that you'd be having a bad time.
You can use Paw to make a "sequence", which I believe will let you take values from headers to reuse. This is also possible with Runscope Ghostinspector.
Looking through some legacy code I have in front of me using struts one, I see:
<global-forwards>
...
<forward name="accessDenied" path="/www/jsp/AccessDeniedForm.do" redirect="true" />
</global-forwards>
So it's just a global forward to send to a access denied page.
I am curious about the decision to redirect as opposed to forward. What are the advantages and disadvantages of using it?
What are the pro's and con's of using it?
Before discussing pro's and con's of using that forward element with redirect set to true, let's understand what is actually going on with that configuration. When redirect is set to true in the forward element, a redirect instruction should be issued to the user-agent so that a new request is issued for this forward's resource. This link will probably provide detail information that you need.
The default value for redirect is to false, essentially when the forward element is called, it forward to that path specified and that's it. If you are setting redirect to true, take for example, the browser will make another request. So I think with these said, you probably know or have an idea the pro and con if you really want to use it.
In redirect, the control can be directed to different servers or even another domain name.The redirect takes a round trip.When a redirect is issued , it is sent back to the client , and redirected URL information is in the header instructing the browser to move to the next URL. This will act as a new request and all the request and response data is lost.
In forward , the forwarding is done from server side , the client browser URL do not change.the data is also not lost.It is just like a browser page refresh. Whatever data posted in the first submit is resubmitted again.So use it with caution.
Both forward and redirect are used in different scenarios ,the global forward should be redirect because it is an error situation.
Redirect is slower as it needs a roundtrip.Forwards are faster.
If you specify
redirect="true", Struts uses a client-side redirect
[response.sendRedirect()]
. The JSP will be invoked by a new browser request, and any data stored in the old request will be lost.