Sure they both present the user with the contents of a new page. But how they do it has ramifications for you web app. With a call to Response.Redirect, the server basically sends an HTTP header back to the client browser with an HTTP status code stating that the object has moved along with the new location to find it.

See the snippet of an example HTTP header below when Response.Redirect("somewhere/newlocation.aspx") is called.

HTTP/1.1 302 Object moved
Server: Microsoft-IIS/5.0
Location: somewhere/newlocation.aspx

This tells the browser that the requested resource (page) can be found at a new location, namely somewhere/newlocation.aspx. The browser then initiates another request (assuming it supports redirects) to somewhere/newlocation.aspx loading its contents in the browser. This results in two requests by the browser.

One ramification of this is that if the initial request was a form POST, the posted form fields are not available in the second request. Likewise query string parameters are unavailable unless the page that issues the redirect explicitly tacks them on. Also, since the browser initiates the second request, it is possible to redirect to a page on an external site.

In contrast, Server.Transfer transfers execution from the first page to the second page on the server. As far as the browser client is concerned, it made one request and the initial page is the one responding with content (this point often confuses new ASP.NET developers as the browser still shows the URL of the initial page even though the content is generated by the second page. It all makes sense when you understand what is happening.).

Well, Response.Redirect simply sends a message down to the browser, telling it to move to another page. So, you may run code like:

Response.Redirect("openalbum.aspx")

or

Response.Redirect("http://www.sneakpic.com/")

to send the user to another page.

Server.Transfer is similar in that it sends the user to another page with a statement such as Server.Transfer("WebForm2.aspx"). However, the statement has a number of distinct advantages and disadvantages.

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.

For example, if your WebForm1.aspx has a TextBox control called TextBox1 and you transferred to WebForm2.aspx with the preserveForm parameter set to True, you'd be able to retrieve the value of the original page TextBox control by referencing Request.Form("TextBox1").

This technique is great for wizard-style input forms split over multiple pages. But there's another thing you'll want to watch out for when using the preserveForm parameter. ASP.NET has a bug whereby, in certain situations, an error will occur when attempting to transfer the form and query string values. You'll find this documented at http://support.microsoft.com/default.aspx?id=kb;en-us;Q316920.

The unofficial solution is to set the enableViewStateMac property to True on the page you'll be transferring to, then set it back to False. This records that you want a definitive False value for this property and resolves the bug.

So, in brief: Response.Redirect simply tells the browser to visit another page. Server.Transfer helps reduce server requests, keeps the URL the same and, with a little bug-bashing, allows you to transfer the query string and form variables.The benefit of this approach is one less round trip to the server from the client browser.