Server.Transfer transfers page processing from one page directly to the next page without making a round-trip back to the client's browser. This provides a faster response with a little less overhead on the server. Server.Transfer does not update the clients url history list or current url. Response.Redirect is used to redirect the user's browser to another page or site. This performs a trip back to the client where the client's browser is redirected to the new page. The user's browser history list is updated to reflect the new address

A common misconception is the difference between Server.Transfer and Response.Redirect in ASP.NET applications. Redirect and Transfer both cause a new page to be processed, but the interaction between the client (web browser) and server (ASP.NET) is different in each situation.

Redirect: A redirect is just a suggestion – it’s like saying to the client “Hey, you might want to look at this”. All you tell the client is the new URL to look at, and if they comply, they do a second request for the new URL.

If you want to pass state from the source page to the new page, you have to pass it either on the URL (such as a database key, or message string), or you can store it in the Session object (caveat: there may be more than one browser window, and they’ll all use the same session object).

e.g. Redirect to the new.aspx page, passing an ID on the query string. "true" stops processing the current page:


Transfer: A transfer happens without the client knowing – it’s the equivalent of a client requesting one page, but being given another. As far as the client knows, they are still visiting the original URL.

Sharing state between pages is much easier using Server.Transfer – you can put values into the Context.Items dictionary, which is similar to Session and Application, except that it lasts only for the current request. (search for HttpContext in MSDN). The page receiving postback can process data, store values in the Context, and then Transfer to a page that uses the values.

e.g. Store a message in the context dictionary, and transfer to the default.aspx page (which can then display the message):


Caveats:


Response.Redirect is more user-friendly, as the site visitor can bookmark the page that they are redirected to.
Transferred pages appear to the client as a different url than they really are. This means that things like relative links / image paths may not work if you transfer to a page from a different directory.
Server.Transfer has an optional parameter to pass the form data to the new page.
Since the release version, this no longer works, because the Viewstate now has more security by default (The EnableViewStateMac defaults to true), so the new page isn’t able to access the form data. You can still access the values of the original page in the new page, by requesting the original handler:

__________________
S.VinothkumaR
Behind me is infinite power,
Before me is Endless Possibility,
Around me is Boundless Opportunity,
Why should I fear!

Server.Transfer or Response.Redirect both are the method of choice for transferring the user from one place in the application to another

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.

The other side debates that Server.Transfer is not user friendly because the page requested may not be the page that shows in the URL. Response.Redirect is more user-friendly, as the site visitor can bookmark the page that they are redirected to.

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").

__________________
Shaalini.S
Be the Best of Whatever you are...

difference between Server.Transfer and Response.Redirect

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("Myform.aspx")
or

Response.Redirect("http://www.discussweb.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("myform.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.

The Server.Transfer method also has a second parameter—"preserveForm". If you set this to True, using a statement such as Server.Transfer("Myform.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 "myform1.aspx" has a TextBox control called TextBox1 and you transferred to "myform2.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").

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, 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.

Don't confuse Server.Transfer with Server.Execute, which executes the page and returns the results. It was useful in the past, but, with ASP.NET, it's been replaced with fresher methods of development. Ignore it.

ThankQ
KiruthikaSambandam