Inscrivez-vous ou connectez-vous pour rejoindre votre communauté professionnelle.
Response.Redirect should be used when:
we want to redirect the request to some plain HTML pages on our server or to some other web server
we don't care about causing additional roundtrips to the server on each request
we do not need to preserve Query String and Form Variables from the original request
we want our users to be able to see the new redirected URL where he is redirected in his browser (and be able to bookmark it if its necessary)
Server.Transfer should be used when:
we want to transfer current page request to another .aspx page on the same server
we want to preserve server resources and avoid the unnecessary roundtrips to the server
we want to preserve Query String and Form Variables (optionally)
we don't need to show the real URL where we redirected the request in the users Web Browser
The main difference between Server.Transfer and Response.Redirect is -> Server.Transfer operation performs within the application, but the Response.Redirect can be used for redirect to outside the application.
For e.g: Suppose there are two pages p1 and p2 in our application, By using Server.Transfer in Page p1 to go to p2, p2 page will show but the url will not change. It is the process for within the application
But if we have to redirect the page to other domains Server.Transfer will not used. Response.Redirect will redirect the page to other's domain page.
In addition to the above answers Response.Redirect can be used to to move to new URL which is in another domain. But Server.Transfer should be used only in the same domain.
Eg. To navigate from yahoo.com to yahoo.com/news you can use Server.transfer, but to navigate from yahoo.com to google.com you cannot use Server.Transfer and Response.Redirect should be used.
Server.Transfer avoid unnecessary round trip, preserve query string and doesn't show url
Response.Redirct make unnecessary round trip, doesn't preserve query string
Server.Transfer() : client is shown as it is on the requesting page only, but the all the content is of the requested page. Data can be persist accros the pages using Context.Item collection, which is one of the best way to transfer data from one page to another keeping the page state alive.
Response.Dedirect() :client know the physical loation (page name and query string as well). Context.Items loses the persisitance when nevigate to destination page. In earlier versions of IIS, if we wanted to send a user to a new Web page, the only option we had was Response.Redirect. While this method does accomplish our goal, it has several important drawbacks. The biggest problem is that this method causes each page to be treated as a separate transaction. Besides making it difficult to maintain your transactional integrity, Response.Redirect introduces some additional headaches. First, it prevents good encapsulation of code. Second, you lose access to all of the properties in the Request object. Sure, there are workarounds, but they’re difficult. Finally, Response.Redirect necessitates a round trip to the client, which, on high-volume sites, causes scalability problems.As you might suspect, Server.Transfer fixes all of these problems. It does this by performing the transfer on the server without requiring a roundtrip to the client.
Redirect returns to the client an HTTP response with the status 302 (found) accompanied with a location header that points to the URL of the new destination that the client should issue a new request for.
Transfer internally (on the server) directs a request to a new handler specified as a path or an IHttpHandler instance. The original handler is terminated and the new handler receives the same QueryString and Form collections. Transfer is used in ASP.Net URL rewriting, which allows users to request pretty and SEO freindly URLs who are internally directed to pages that use ugly URL parameters.
Key difference is Response.Redirect happens at the user's machine in his/her browser so it requires an extra roundtrip to the user machine from the server side code. On the other hand Server.Transfer does happens at the server and thus avoids the need to roundtrip to the the user browser.
Response.Redirect from Page A to Page B:
Browser Requests Page A -> Server responds with Page A but with a redirect request to Page B -> Browser sees the request to redirect. So it requests Page B -> Server responds with Page B
Server.Transfer from Page A to Page B:
Browser Request Page A -> Server realizes that it needs to transfer to Page B so it transfers to Page B and sends Page B
Page A and Page B need not be on the same server for Response.Redirect to work however they need to be on the same server for Server.Transfer to function.
The biggest difference is that Response.Redirect lets the browser know where it will navigate to while server.transfer only performs a server side rendering of a webform and sends this output to the browser. Response.Redirect on the other hand sends a signal to the browser with the next url (+ querystring!) to the browser so that this one can request the next page (to where you are redirecting).
Here:
