ISerializable - Roy Osherove's Blog

Redirect, issues a 304 (http code) to the browser and the broser navigates to the next page.

Tansfer, changes the server processing of the HTTP reguest and start ejecuting anothe page without sending anything to the browser.

Cool, I hadn't seen the context.items before.

I've just used querystrings in the past.

One important difference : redirect emits a silent exception.

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

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.

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

Server.Transfer vs. Response.Redirect
A user sent me this blurb out of Wrox's ASP 3.0 Programmer's Reference regarding the differences between Server.Transfer and Response.Redirect:

The current page's context is also passed to the target page or resource. This includes the values of all the variables in all the intrinsic ASP objects, such as the collections of the Request, Response, and Session objects, and all their properties. The Application object context is also transferred, even if the page is within a different virtual application. The current transaction context is also passed to the new page, allowing it to take part seamlessly in any current transaction.

Meanwhile, the browser's address bar still shows the original URL, and the Back, Forward, and Refresh buttons work normally. When we use client-side redirection, especially with an HTML meta tag, this usually isn't the case.

However, the values of any script variables or object references that were created or set within the first page are not available within the new page.

One other major difference is that because Server.Transfer doesn't require the client to request another page, it can be faster in some cases, depending on what you're doing.

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:

In case of Server.Transfer does not update the clients url history list or current url.
In case of history list is updated to reflect the new address

Response.redirect: Ex: Response.Redirect("webform1.aspx?id=" & txtfrm2.Text & "") Server.Transfer: Ex: Server.Transfer("webform1.aspx?id=" & txtfrm2.Text & "") Both r similarly same and slightly different. i.e response goes to redirect the value to another page where as tranfer goes to the value thr control also...in asp.NEt

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.