Two approaches to redirection in ASP.NET
Directing a user to another page or resource is a
common aspect of a web application. The user may initiate the transfer
to another page any number of ways, including clicking a button or link
or selecting a value in a drop-down list.
ASP.NET provides a few ways to move to different pages. Here's a look
at these options, along with commentary on when you should use which
Client vs. server
A key aspect of the various ways to send a user to another page
within an ASP.NET application is where the transfer occurs; that is, it
is handled within the client browser or on the web server. The following
list outlines options for controlling page navigation.
- Response.Redirect: the Redirect method of the Response object provides a way to implement client-side redirection.
- Server.Transfer: the Transfer method of the Server object performs redirection using the server and avoiding HTTP requests.
- Server.Execute: the Execute method allows you to
call another URL without actually navigating to the page. The page is
executed and control returns to the current page when finished.
Let's take a closer look at each approach.
The default behaviour of the Response.Redirect method is
execution of the current page halts, and the user is sent to the new
URL. The web server issues HTTP headers and sends a 302 response to the
client browser; this instructs the client to make redirected calls to
the target URL. The result is two server requests for each redirection:
the original and redirected requests. The following C# snippet shows it
Now, the Redirect method has two signatures with the second format
accepting another Boolean parameter that signals whether execution of
the current page should terminate (the default behaviour). We could tell
the system to continue execution of the current page while redirecting
the user to the News.com site with the following snippet:
The Server.Transfer method transfers the execution of a target
URL to the server and halts execution of the current page. The result is
only one request (as opposed to the two involved with the
Response.Redirect method) since the server does not notify the client
browser of the change. The experience can be a little disconcerting for
users since the page address does not change in the browser. This C#
snippet shows how you may use this method.
When using Server.Transfer, the target URL must be a virtual path on
the same server since the web server's worker process is used, so you
can't use an address containing "http" or "https". It has three
signatures, with a second variation allowing you to transfer control to
an IHttpHandler and the third adding a second parameter to the first
version; whereas, the second value is a Boolean signalling whether the
current form's querystring and Form collections are preserved.
The PreviousPage property of the Page class provides code access to
properties of the previous page in the browsing session, so Form and
querystring variables are persisted between pages whereas they are not
when using Response.Redirect.
The Server.Execute is a bit antiquated, as there are other ways
to accomplish the task, but it basically allows you to execute a
resource request without leaving the current page. It has five
signatures, but the basic version accepts a path to a resource as the
following snippet displays:
Pros and cons of each approach
Redirecting a user to another web resource is feasible in ASP.NET
using one of the techniques discussed. However, you may be wondering why
you would choose one approach over the other. The following list covers
some of the advantages or disadvantages of Server.Transfer and
- Bookmarking: since Server.Transfer does its work on
the server, the address within the client browser is not updated. The
user sees the previous page's address while viewing a new page.
Consequently, the user is unable to bookmark certain pages.
- Page refreshes: there is an issue when a true value
is used with the second parameter of the Server.Transfer method. When
users refresh a page located via this approach, it can trigger an
invalid ViewState error message. This can be alleviated by disabling the
enableViewStateMac property on a page, but this isn't the best approach
- Performance: Response.Redirect introduces an extra
call while making the round trip between client and server; since there
is only one call with Server.Transfer, it offers better performance.
- Scalability: the extra round trips associated with
using Response.Redirect are often stated as a drawback with using it.
However, I have seen it used in large applications without experiencing
any performance issues.
- Errors: while Server.Transfer can cause some user
confusion as the URL displayed in the browser address bar, it can also
lead to some confusion with error logging, as the page URL recorded
during logging will display incorrectly.
- Basic security: an interesting twist with using
Server.Transfer is the ability to send data to another page without the
user seeing it. This is enabled via the use of the QueryString, which is
appended to the end of the target address. This new address will not
show in the browser address bar with Server.Transfer, so it offers a
simple layer of security. Of course, the Response.Redirect approach
makes the QueryString visible to the user.
Usage depends on the situation
ASP.NET offers plenty of options when tackling a development task.
The Response.Redirect and Server.Transfer methods provide two ways to
redirect users to new URLs. Each method offers its own set of positive
attributes, so deciding which one to use is really up to the developer's