ASP.NET - Server.Transfer v/s Response.Redirect

home
asp.net
view story

17 Kicks

Kick It

Drop Kick

Kicked

ASP.NET - Server.Transfer v/s Response.Redirect(techahead.wordpress.com)

submitted by prashantvictory(605) 4 years, 7 months ago

This article tell you the difference between Server.Transfer and Response.Redirect.

7 comments |category: ASP.NET |Views: 67
Tweet

tags: Response.Redirect TechAhead ASP.NET Server.Transfer another

Everyones tags:

Your Tags:

Please login or signup.

Add a live kick counter to your blog >> liveImage

You can even customize the image by choosing your own colors, and then clicking the button below to update the preview and the html code:

"Kick It" text
"Kick It" background
kick count text
kick count background
border

Simply copy and paste this HTML into your blog post.

Users who kicked this story:

More who kicked this story...

Comments:

posted by simoneb(5450) 4 years, 7 months ago 0

No guys, this is a terrible explanation, look for this topic on Phil Haack's blog (http://www.haacked.com), THAT is an explanation.

posted by senfo(881) 4 years, 7 months ago 0

Here is the story that simoneb is talking about:

http://haacked.com/archive/2004/10/06/responseredirectverseservertransfer.aspx

posted by senfo(881) 4 years, 7 months ago 0

I recommend avoiding Server.Transter( ) in nearly all situations. I've seen people save almost an entire form in context and then read the values back on the new page. This is a horrible idea because it ties the second page with the first page. I have no problem with one page complementing another page (e.g, passing search criteria in a query string to the next page), but if one page absolutely relies on the previous page (e.g, saving the value of every control into Context and reading it back on the second page) you're better off just using panels that are hidden and displayed when appropriate.

On that note, one good use that I have found for a Server.Transfer() is when transferring to a summary page after, for example, a user has made a purchase. This prevents the user from hitting the back button and having their credit card charged twice. Other than that, saving a single additional request from the client, there isn't much else I have found to gain, but a lot more to loose.

In my not so humble opinion, it's almost never a good idea to break browser URL's. And no, URL rewriting is not the right answer --it's another hack that is very specific to the implementation. Also, I've run into situations where developers have used Server.Transfer() for every single request. This ends up breaking the browsers back button and frustrates users, which is also not a very smart thing. Lastly, every developer that I know that makes exclusive use of Server.Transfer() ends up making the mistake of saving [nearly] every control value into context before transferring and then reading the values back on the new page. Any time you update either page, you have to make sure you haven't broken anything. This is just silly and should definitely be considered bad practice.

posted by prashantvictory(605) 4 years, 7 months ago 0

Hi simoneb,
Why you thinks that its a terrible article,
I am not agree with you, its not because this is my article, but its caz its contains almost each and every aspect about this topic, the article you have given is also contains the same things, i have explained my article more clearly, so that a beginner can understand, your article is explained in more advanced way, or you can say that its explained so much in deep which most of the pepole not requires, a beginner or a developer who's not having much expertise abt asp.net can't understand such things. and most of the times we require good and understandable explanation, and in your article it is explained so much in deep, which only goiod for knowledge.:D
but its good to read that article after reading my article, caz moving from simplest to advanced is the way to move on....
take care.:d

posted by lakshmitalwar(1) 1 year, 6 months ago 0

:)nice article

Most Active Users

What's this?