I understand that most of the languages support server side redirects (asp.net: Response.Redirect, PHP: header( 'newpage' ) ; ). You could also do a redirect with JavaScript (window.location.href="newLocationURL").
When would you choose one over the other ?
With respect to ASP.net/IIS7(app pool in Integrated mode,enable 32 bit apps=false), I noticed that even when the page has a 302 header, the whole page body is sent to the client side.
And I believe this is not the case with PHP, only headers are sent ? To quote
Redirect on client side means following steps:Client-side -> Server-side -> Client-side -> Server-side -> Client-side.
Redirect on Server-Side means:Client-side -> Server-side -> Client-side (headers only)* -> Server-side -> Client-side.
Is there a W3C standard or server side redirect implementation differ from one web server technology to another ?
Edit: I am only concerned about Response.Redirect (in asp.net) and not server.transfer, at least for this discussion
The JavaScript example is actually not a redirect. There's no means of a 301/302 response. It is just a simple request which happens during a certain Javascript event long time after the page is arrived. If you do this during page load, then it would have more overhead than a real redirect and it would not work on JS-disabled browsers as well.
Redirects are to be initiated from the server side with a 301/302 response. All webapp languages/frameworks defaults to 302. You can usually make it 301 by adding one extra parameter or code line which instructs that. The benefit of 301 is by the way that the particular request won't be indexed (anymore) by the searchbots.
In ASP.Net, there is an important distinction between two kinds of server-side redirects. They are Response.Redirect and Server.Transfer.
If you call Response.Redirect, that entails two round trips to the server. On the first call to the server, the server response directs the browser to request the next page. Requesting that next page constitutes the second round trip to the web server.
If you use Server.Transfer, there is only one round trip. Therefore, there is much less network traffic. However, there is a limitation to using Server.Transfer, which is that the target page has to be on the same web server. That is, you can't Server.Transfer from your web app to www.Google.com. But you can Response.Redirect to it.
There are other details involved with using either of these approaches which you would want to research before using them. However, I believe that it is significant in the context of this question to note that in any language, Response.Redirect may result in much heavier network traffic than is really necessary.
It really depends on where you decide that you need to redirect. If it is server side code that determines that you have to redirect, then it is server side code that issues the redirect command. If you can decide client side that a redirect is needed, then do it from the client code.
It is probably more efficient from client side, since you avoid a the back-and-forth of the server side redirect thing..
Related
I'm asking this one for the record:
So I have a client making an Ajax call and I'm trying to have the server handle it and redirect the client server-side.
The express docs make it seem res.redirect(path) is going to actually send a response from the server for the client to redirect(re-route).
e.g.
var path = 'http://localhost:8080/newRoute';
res.redirect(path);
//the client will now go to http://localhost:8080/newRoute
But it appears that this only tells the client to make another request to
the url given.(Which seems useless, but that is what my network requests are showing currently).
Many suggest to do the following to do an actual redirect server-side
var path = 'http://localhost:8080/newRoute';
response.writeHead(302, {'Location': path});
response.end();
So does this mean that that we need to change the header in order for the redirect work?
i.e.
res.location('http://localhost:8080/newRoute');
res.redirect('http://localhost:8080/newRoute');
But the above looks horribly redundant and makes res.redirect look like it wasn't intended for server-side redirects to a new page.
Yet the Express docs show an example like this:
res.redirect('http://google.com');
which I don't know how that could be interpreted any other way than "send the client to the page 'http://google.com' ".
Big Question:
So is res.redirect(path) suppose to handle server-side redirects? If not, what do we do?
Question
How should a well-designed application handle 301 "moved permanently" redirects upon http POST to restful api?
Context
Our hosted application offers a restful api
We have a customer extensively who uses our restful api in their own 'on-premise' application [fwiw, installed at dozens of sites-- with no easy way to update]
We are migrating our application to a new data centers and in the process we will switch them (and others) from 'plain text http' to 'ssl-encrypted https'. [The physical location data center of course is irrelevant, but the new data center has more stringent security rules and thus mandates https]
Our front end (haproxy/nginx) will send a 301 'Moved Permanently'
This 301 redirect preserves query parameters but loses post data
I know that "restful api's should be permanent", but, merde arrive (that's shit happens in French)--Empires crumble, Berlin Wall falls, Oracle buys Sun etc.
The Problem
Their application makes HTTP post calls to our restful api. When the front end returns 'http status 301', their application does not 're-post' to the new url, and the update fails.
Questions
How should error handling handle 301's as well as other http statuses? ( pseudocode will suffice)
Should our 'front end' do something different for '301'?
To fulfill your "well-designed" requirement in the sense of "pure RESTfulness", the client should re-send the request to the new URI. A response code of 301 indicate the resource has moved, and cannot be used to fulfill the request, so there's really no fallback position.
If the client attempts to re-post, but loses data, that's a client bug. The "correct" behavior of a client varies by your requirements: it could treat the redirect as a recoverable error case, and repost transparently; it could repost while instructing the user to update the endpoint; or it could fail with an appropriate error message.
I want to Do a proxy redirect from perl. I have been using Location Header to redirect.
print ("Location: http://www.example.com\n");
The problem with this is the url on the client side changes to a new one (i.e. www.example.com ). I don't want that to happen, so that the end user is unaware of the location we are serving the request from.
If the client is going to do the fetching, it's going to show the URL it's fetching unless the page being fetched is embedded in another page (e.g. by using an iframe). And even then, it's very easy for the user to discover the url if they look.
If instead you do want to a be a proxy (and by all indication you are), which is to say you want to fetch a doc and return it to the client, well, you have to start by fetching the doc you want to return to the client.
Note that you can configure apache to act as a proxy.
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.
Why does using Fiddler break my site sometimes on page transitions.
After a server side redirect -- in the http response (as found in Fiddler) I get this:
Object moved
Object moved to here.
The site is an ASP.NET 1.1 / VB.NET 1.1 [sic] site.
Why doesnt Fiddler just go there for me? i dont get it.
I'm fine with this issue when developing but I'm worried that other proxy servers might cause this issue for 'real customers'. Im not even clear exactly what is going on.
That's actually what Response.Redirect does. It sends a 302 - Object moved response to the user-agent. The user-agent then automatically goes to the URL specified in the 302 response. If you need a real server-side redirect without round-tripping to the client, try Server.Transfer.
If you merely constructed the request using the request builder, you're not going to see Fiddler automatically follow the returned redirect.
In contrast, if you are using IE or another browser, it will generally check the redirect header and follow it.
For IE specifically, I believe there's a timing corner case where the browser will fail to follow the redirect in obscure situations. You can often fix this by clicking Tools / Fiddler Options, and enabling both the "Server" and "Client" socket reuse settings.
Thanks user15310, it works with Server.Transfer
Server.Transfer("newpage.aspx", true);
Firstly, transferring to another page using Server.Transfer conserves server resources. Instead of telling the browser to redirect, it simply changes the "focus" on the Web server and transfers the request. This means you don't get quite as many HTTP requests coming through, which therefore eases the pressure on your Web server and makes your applications run faster.
But watch out: because the "transfer" process can work on only those sites running on the server, you can't use Server.Transfer to send the user to an external site. Only Response.Redirect can do that.
Secondly, Server.Transfer maintains the original URL in the browser. This can really help streamline data entry techniques, although it may make for confusion when debugging.
That's not all: The Server.Transfer method also has a second parameter—"preserveForm". If you set this to True, using a statement such as Server.Transfer("WebForm2.aspx", True), the existing query string and any form variables will still be available to the page you are transferring to.
Read more here:
http://www.developer.com/net/asp/article.php/3299641/ServerTransfer-Vs-ResponseRedirect.htm