I have recently been involved in an interesting debate whether to have development teams utilize Server.Transfer or Response.Redirect as the method of choice for transferring the user from 1 place in the application to another.
One side debates Response.Redirect is not a scalable solution because of the performance hit it causes because it has to ask the client browser to please request this next page using a 302 header. Which really, I think they should be using the point that Form and Query string variables are not persisted between pages using the Response.Redirect instead you have to stick information into Session which can be problematic in itself sometimes. I have personally coded on some very large, high volume sites that use nothing but Response.Redirect and the application scaled just fine.
The other side debates that Server.Transfer is not user friendly because the page requested may not be the page that shows in the URL. And, if the user hits the “Refresh” button then basically the code has to execute all the way from the page the user originally started from to the last page the actually viewed in the process. Not to mention, the Microsoft bug where if you do a Server.Transfer(”page.aspx”, true) you will get an “Invalid ViewState” error. Which may cause the developers to want to disable the enableViewStateMac which I personally don't think is a very good security practice. Also, your application could potentially run into a “stack overflow” situation if a developer does a Server.Transfer to the same page. It has been a while but I also think Server.Transfer doesn't invoke PrincipalPermissionAttribute security on the target page when transferring to it.
I am curious what other people in the ASP.Net community think about this. I really have just summarized the conversations we had over this topic so please expect that I have missed some details. Personally, I think both have pros and cons but with that they are also were created to meet different development needs for different situations. So, locking it down and forcing a team of developers to use one way or the other for every situation is a recipe for disaster.