Response.Redirect vs. Server.Transfer
I see the question from time to time on ASP.NET related forums and message board quite often asking what the difference is between Response.Redirect and Server.Transfer. I remember about four years ago when I too was pondering this question and where should I use each method. I think it is still a valid question for the ASP.NET comunity, especially since we seem to have many newbies entering the .NET world right now. The answer can be summed up fairly simply, Response.Write sends a redirect to the browser and Server.Transfer moves processing from the original page to the target page on the server.
If we dive into the actual mechanism of each method there is a drastic difference. Response.Redirect is the much simpler method and has been with us since the old Classic ASP days. The way this method works is it sends a 302 redirect to the browser. 302 refers to the status code, I talked a little about IIS Status Codes almost a year ago. It also adds the target URL to the header of the request. because some browsers do not process redirect headers, possibly as a security feature the method also pushes some code in the body of the response to let the user know they should mannualy go to the new page, which most of us have seen at one time or another.
<h2>Object moved to <a href=[http://WhateverURLYouNeedGoesHere">here</a>.</h2>
If you need to send any values to the final destination you will need to pass them in the QueryString so the next page can process them accordingly.
The main problem with the redirecting method is it requires a full round trip to and from the server and often back to the same server. This is where Server.Transfer comes comes in handy. Server.Transfer actually transfers the request from one page to another, never leaving the server. That is why you can not server.transfer to another domain. The actual URL displayed in the browser does not change because the browser believes it is the same URL and has no conscienceness of the transfer. In reality the page life-cycle never changes as it moves from the processing code of the first page to the second, it just picks right up as if the two pages were one. The content that is render to the client browser is that of the second page and nothing from the first page.
Under the hood the Transfer method involves a chain of events that perfoms many checks before transferring the request to the target page. The method actually checks to make sure the user has permission to execute the page, which is a real important security mechanism. It then handles the passing of the processing and preserving of the page state, controls, etc to the target page.
Each have their place, response.write is used more often than server.transfer, but I think that is because so many learned to do that in the old ASP days. With transfer you actually retain access to the objects of the page that initiated the post-back, where with response.write you would have to pass a set of querystring parameters. ASP.NET 2.0 also introduced the Cross-Page Post back, which is very similar to Server.Transfer. For many ASP.NET programmers it is sometimes difficult to use the Server.Transfer method, but we should all take some time to build our comfort level with this handy mechanism.