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