Reponse.Redirec t vs Server.Transfer

[Steven Nagy]

Hi all,

What are the major considerations when considering Server.Transfer ?
I have some legacy apps (when I say legacy, I mean ASP.NET1.0) that use
Server.Transfer for almost everything. I always thought
Response.Redire ct was better because more of the items are GCed. So I
am rethinking about the importance of Server.Transfer usage. In the old
ASP days I seem to remember (I could be wrong) that when I did a
Server.Transfer , all objects on the old page were still available to be
accessed in the new page. However this doesn't seem to be the case in
..NET and indeed would seem somewhat contradictory to an OO paradigm.

So I guess I just want to know when to use Server.Transfer , and what
should I be considering about memory usage and GC and so on.

Many thanks,
Steven

[Barry Kelly]

"Steven Nagy" <le*********@ho tmail.comwrote:

What are the major considerations when considering Server.Transfer ?
I have some legacy apps (when I say legacy, I mean ASP.NET1.0) that use
Server.Transfer for almost everything. I always thought
Response.Redire ct was better because more of the items are GCed.

The two have different semantics. Server.Transfer continues processing
on the server, but on a different URL on the server. Response.Redire ct
sends an HTTP redirect back to the client, and exits the server. The
client then reconnects on the new URL.

With Response.Redire ct, the client's URL changes. With Server.Transfer ,
it doesn't.

Your choice should be based on which semantics you need.

-- Barry

--
http://barrkel.blogspot.com/

[Steven Nagy]

So there's absolutely no other considerations?
Server.Transfer still GCs to the same extent as Response.Redire ct?

So Response.Redire ct is actually quite time consuming?
Since it sends a response back to the client telling it to request a
new page?
That's a whole extra round trip right?
In that case, why EVER use Response.Redire ct ?

Thanks,
Steven

[Barry Kelly]

"Steven Nagy" <le*********@ho tmail.comwrote:

So there's absolutely no other considerations?
Server.Transfer still GCs to the same extent as Response.Redire ct?

Garbage collection has nothing to do with it. With a redirect in a
load-balanced environment, the client might not even enter the same
server. Certainly, objects associated with the current request will no
longer be rooted and will be eligible for collection, since request
processing will cease and the request thread will exit back out to
ASP.NET.

So Response.Redire ct is actually quite time consuming?
Since it sends a response back to the client telling it to request a
new page?
That's a whole extra round trip right?

Yes.

In that case, why EVER use Response.Redire ct ?

When pages move? So that the target URL can be bookmarked? To transfer
control to a different website?

-- Barry

--
http://barrkel.blogspot.com/

[Carl Daniel [VC++ MVP]]

Barry Kelly wrote:

"Steven Nagy" <le*********@ho tmail.comwrote:

>In that case, why EVER use Response.Redire ct ?

When pages move? So that the target URL can be bookmarked? To transfer
control to a different website?

....or my favorite - to make the browser to a GET after a POST so that the
back button works sensibly. Totally contrary to the ASP.NET POST-centric
model, but the user experience is so much better.

-cd

[Steven Nagy]

Ok thanks guys. I guess I need to use Server.Transfer a bit more then.
When none of those reasons you supplied are relevant, then
Server.Transfer is the way to go to save the round trip.

Thanks again peeps.