7/28/2019 Response.redirect

1/2

In-depth analysis of Response.Redirect and Server. Transfer in ASP.Net

We go from one page to the other in asp.net without ever caring to go deep inside the undergoing mechanisms. So

the interesting world of page navigation lies all unearth, mysteriously laying all bare to all those who are really

curious..Same was the case when I just stumbled upon one of these methods which indirectly led me to dig into other

methods even deeperlets start the adventure now.

Let us go and recover some secrets from the most common of all the methods we use every now and then.

1. The Response. Redirect:

Now this ones is actually a Client Side redirect.

Whenever we call upon the Response. Redirect, the server sends in response 302 to the client telling the client to

make the redirect to the URL required.

So what actually is happening is that this is a story of two requests being negotiated by the server during each

request. The first one is the one we requested and the other being the redirected one. Hence in a way it can be said

that SeverResource is being consumed twice.

protected void Button1_Click(object sender, EventArgs e)

{

Response.Redirect("Page2.aspx");

}

Now lets do a bit more postmortem.

Response.Redirect(url);

Here url is thee Uniform Resource Locator to which the browser is redirected to on being called, which can also

include query string. But since Query string also has its own limitation and due to the inherent sever round tripping

phenomenon associated with the Redirect method, its not advisable to use it when we require to send in large

amounts of data.

Note: the Request object represents an HTTP request before it has been sent to the servers so the Response object

tells its Redirect object to fetch the url requested by sending a header to the client. This header tells the client to find

the url in the location specified in the header. Since we all know that the header is placed on the top of a document

(in the beginning) so its actually impossible to call the Redirect method in the pages containing HTML code preceding

it. But do not worry we can also overcome this problem by using buffering. Its interesting to note that Responseobject has the buffering capability, so we can put the HTML code in the buffer till the Response. Redirect is called

upon. After its called we can clear the buffer.

But all said against poor old Response. Redirect method we must also remember that Response. Redirect is very user

friendly . Thus a user who visits a page he is redirect to can easily bookmark that page.

DO note that You can't redirect to a master Page. Well as foolish it may seem but it is true because a Master page is

the template whose design is going to be shared by all other pages who have inherited it(i.e the Content pages). So

you can only redirect to content pages in asp.net project.

7/28/2019 Response.redirect

2/2

2. Server. Transfer:

Now remember during Server. Transfer also, post back occurs but this time around the sever transfers the execution

of the requested url to the server itself. So unlike the client side redirection there is no round trip.

To the normal user this all seem alike. But in fact what happens here is that although the user sees the url on the

browser being pointed to the original url, its actually being handled by the target URL. Now when the target url posts

backs to the server, at that time the browser URL is updated to the target URL. So unlike the Response. Redirect

where we could we could bookmark the redirected page, here we cannot do the same initially, because it is still

pointing to the original URL.

Well all this means that the transferred page appears to the client as a different url than they really are, thus relative

links / image paths may not work, when we are transfer to a page from a different directory.

Remember that since all this requires the effort of the server, this can only work on those sites running on the server

you own. We cannot transfer our client to any other external website url (since its hosted on a totally different

server).

Moreover Sever. Transfer also has another method called Preserve Form, which when set to true like in the codeshown below, we can still be able to access the original query and the page controls in the page we are transferred to.

protected void Button1_Click(object sender, EventArgs e)

{

Server.Transfer("Page2.aspx", True);

}

So when we have a Texbox control say tbx1 in our form then we can access it in our transferred page by the

following code :

Request.Form("tbx1");

This is actually because since the release of the feature, View state has also been enhanced in it security aspect. So

we are unable to access the controls or data on the previous form. But there lies a hack to overcome this hurdle.

In order to solve it all we have to do is set the enableViewStateMac to true on the transferred page and then again

set it back to false. This will tell it that you need this property to remain false always.

Last but not the least another side effect of

Server. Transfer is that it doesn't go through the normal server pipeline and hence it bypasses any URL restrictionthat has been imposed in the web.config files.

So with a small bug and some side effects with it and the advantage of reducing server load we can leave

Server.Transfer.