Response.Redirect vs Server.Transfer

code 0 comments suggest edit

When conducting phone interviews, I like to ask a few technical questions just to make sure that a candidate isn’t trying to blow smoke up my… well we don’t need to be overly illustrative do we?

I absolutely do not intend the questions to be nitpicky. Nor do I feel they are totally representative of an interviewee’s depth of knowledge. I save the probing questions for an in-person interview.

However, if a candidate claims to have one or two years experience working with ASP.NET, there are some basic facts and principles that a mid-level developer should know.

For example, please compare and contrast the result when calling Response.Redirect and Server.Transfer from within a Page class. It boggles my mind that most candidates I talked to couldn’t answer this question. These methods are used quite commonly and the differences are important.

Sure they both present the user with the contents of a new page. But how they do it has ramifications for you web app. With a call to Response.Redirect, the server basically sends an HTTP header back to the client browser with an HTTP status code stating that the object has moved along with the new location to find it.

See the snippet of an example HTTP header below when Response.Redirect("somewhere/newlocation.aspx") is called.

HTTP/1.1 302 Object movedServer: Microsoft-IIS/5.0Location: somewhere/newlocation.aspx

This tells the browser that the requested resource (page) can be found at a new location, namely somewhere/newlocation.aspx. The browser then initiates another request (assuming it supports redirects) to somewhere/newlocation.aspx loading its contents in the browser. This results in two requests by the browser.

One ramification of this is that if the initial request was a form POST, the posted form fields are not available in the second request. Likewise query string parameters are unavailable unless the page that issues the redirect explicitly tacks them on. Also, since the browser initiates the second request, it is possible to redirect to a page on an external site.

In contrast, Server.Transfer transfers execution from the first page to the second page on the server. As far as the browser client is concerned, it made one request and the initial page is the one responding with content (this point often confuses new ASP.NET developers as the browser still shows the URL of the initial page even though the content is generated by the second page. It all makes sense when you understand what is happening.).

The benefit of this approach is one less round trip to the server from the client browser. Also, any posted form variables and query string parameters are available to the second page as well (however these can be cleared by passing in false for the second parameter).

One thing to be aware of is that if the first page wrote something to the Response buffer and you don’t clear it, then any output from the second page will be appended to the output of the first. This is often the cause of a weird behavior where it seems that a page is returning two different pages. Also, since the transfer happens on the server, you cannot transfer a request to an external site.

You’ve been warned. Make sure you wow that next interviewer with your knowledge of ASP.NET.

For extra points, explain how ASP.NET sometimes returns a “View State Is Invalid” error message when you call Server.Transfer(“URL”, true). The explanation is here.

Also, note that the “Response” and “Server” objects I refer to are properties of the System.Web.UI.Page class. The types for these objects are System.Web.HttpRequest and System.Web.HttpServerUtility respectively.

If you like understanding how things work under the hood, I highly recommend Fritz Onion’s book, Essential ASP.NET 2.0. It is personally my favorite book on ASP.NET as it covers only what is essential, but at a deep enough level to really get something out of it.

His 2.0 book is actually a continuation on his 1.0 book, Essential ASP.NET With Examples in C#.

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.



41 responses

  1. Avatar for Dennies
    Dennies March 13th, 2005

    Good Stuff

  2. Avatar for S
    S March 16th, 2005

    Not your everyday geeky article

  3. Avatar for Jo
    Jo March 31st, 2005

    Easily understandable. You rock!

  4. Avatar for Nikunj Thakkar
    Nikunj Thakkar April 4th, 2005

    Can u explain details about second parameter of Response.Redirect

  5. Avatar for T Mercer
    T Mercer April 15th, 2005

    What you say is true, however, if you have to integrate with an existing application that is written in a different language classic ASP or PHP or whatever ... guess what ... Server.Transfer does not work! You cannot mix application you will get an Error in child process.

    Still working on this issue.

  6. Avatar for John
    John April 20th, 2005

    Not a bad article... pity about the condescending tone though...

  7. Avatar for Matthew
    Matthew April 28th, 2005

    Nice little bit. In response to Nikunj, the second parameter of Response.Redirect controls if the current thread will be killed or not. By default it is killed. While debugging this can throw some threading exceptions. To avoid the exceptions, pass false for the second parameter.

  8. Avatar for Matthew
    Matthew April 28th, 2005

    Oh, another comment to Mercer. You really need to understand how your web application technologies work. If you're expecting Server.Transfer to allow you to work from ASP.NET to PHP or old ASP, then you really don't get what's happening. You must use Response.Redirect if you want to move from ASP.NET to another web app technology. =/

  9. Avatar for Matthew
    Matthew April 28th, 2005

    Oh, another comment to Mercer. You really need to understand how your web application technologies work. If you're expecting Server.Transfer to allow you to work from ASP.NET to PHP or old ASP, then you really don't get what's happening. You must use Response.Redirect if you want to move from ASP.NET to another web app technology. =/

  10. Avatar for Mr. A
    Mr. A April 29th, 2005

    A word for the wise, uppon authentication the first response to the client should be a 302 "response.redirect" to avoid POST replay issues. ;)

  11. Avatar for Naroor Rathish
    Naroor Rathish May 3rd, 2005

    Was very informative.thanx a lot.

  12. Avatar for Sandy
    Sandy May 8th, 2005

    another difference:

    Srever.transfer stops the execution of the current page and starts the execution of the page that it transfers while response.redirect the current page is fully executed.

  13. Avatar for Nelson
    Nelson May 11th, 2005

    Nice explication, thank you. gl2all

  14. Avatar for Kevin Slamaker (enigmatic@inte
    Kevin Slamaker (enigmatic@inte June 15th, 2005

    Wonderful stuff.

    Thought it does suffer from a few problems. Even after SP1 for the 1.1 framework using Server.Transfer(<page>,true) when dealing with a click event will cause a Stack Overflow. This is due to the click event (which is stored using 2 hidden fields on the form) being re-raised over and over again with the preserved form data.

    There is a workaround (See Issue 839521 at Microsoft) but it certainly isn't pretty and most corporations are not overly happy with installing a hotfix for a single issue.

    The question I have though is what happens with the HttpHeader information when you use Server.Transfer and preseve the form data. My suspicions are that you cannot influence the current collection of headers at the point in time you are handling the click event and thus as it is simply switching to a new webpage, only the existing header information is carried forward.

    This can then make certain changes to the state of the system difficult when performing such an event, the form fields are already populated (and are now in the response so you cannot modify them), the viewstate is already set and the only thing you really have access to is the session state but this is not useful when the user is allowed to have multiple windows open at the same time.

    Personally I just dont understand why Microsoft implemented a mechanism to make it "like" windows events when it causes so many problems

  15. Avatar for Girish
    Girish June 18th, 2005

    Keep it man, good article.

  16. Avatar for Simone Busoli
    Simone Busoli March 31st, 2006

    The Server.Transfer bug you link to is no longer affecting ASP.NET since 1.1. You're a bit out of date :)

  17. Avatar for Ingo-Stefan Schilling
    Ingo-Stefan Schilling May 3rd, 2006

    Well, I am sorry but I just have the same experience with ASP.NET 1.1 and Server.Transfer bug (even though I have all ServicePacks installed.
    Therefore, Simone, I think you are wrong. At least, I am expierencing the same problems like Kevin and now I am going to see the MS article mentioned in Kevins posting to see if it helps :.(

  18. Avatar for Ingo-Stefan Schilling
    Ingo-Stefan Schilling May 3rd, 2006

    And if you overcome the above mentioned error you might find helpfull afterwards :o) ... well, Roundtrip with Server.Transfer seems no good idea - and that is what I wanted... anyways.

  19. Avatar for Mujjammil
    Mujjammil May 25th, 2006

    Sir, I liked your explaination, but can you explain what is round trip? Please. As I assume if link is clicked on browser, browser sends request to server, then server sends resonse, and something in details please.

  20. Avatar for Ingo-Stefan Schilling
    Ingo-Stefan Schilling June 27th, 2006

    the round trip I was wanting to realize wasn't a round trip in the 'usual' meaning, more a round trip between one or more aspx- pages...
    Even though this idea does look 'stupid' the first glance, it can make sense in at least some scenarios.
    In mine, I wanted to overcome the limitation of some WAP- devices in terms of redirection. Therefore the base idea in my mind was to transfer on server- side and transfer- back after the job was done... well, since my mentioned problems, I 'simply' redesigned my architecture (and made it better - of course ;) and now I do not have this problem anymore.
    I hope Microsoft is going to change this issue anyways, since it would have saved me some days of work since I planned the rearchitecturing for optimization processes later on...
    I hope I was able to answer your question more detailed.

  21. Avatar for Haacked
    Haacked June 27th, 2006

    Well it sounds like what you want is Server.Execute() rather than Server.Transfer.

  22. Avatar for Tian van Heerden
    Tian van Heerden August 9th, 2006

    To Ingo-Stefan,
    You should use Response.RedirectToMobilePage in WAP sites. This is more reliable across the many mobile platforms out there.
    Also, it will always raise a RedirectException (or something like that) which you can trap and ignore (as per Microsoft's recommendation ;-)
    Hope this helps,

  23. Avatar for vipin mishra
    vipin mishra August 24th, 2006

    i like this Explanation

  24. Avatar for mahesh
    mahesh August 31st, 2006

    Really good, and better understandable explanation....

  25. Avatar for ohioboy
    ohioboy September 5th, 2006

    Good article!

  26. Avatar for dj
    dj October 4th, 2006

    I've read some where that Sever.Transfer can lead to broken links in the case where the links are relative. The browser does not "know" that it is on a different page. If there is a relative link it will try request the page relative to the original page it requested rather than the link relative to the current page. Is this true?

  27. Avatar for Bec
    Bec October 13th, 2006

    This article was extremely helpful in helping reslove a few issues I was having with Response.Redirect.
    Now that I have changed to Server.Transfer I am not experiencing the bugs I was with the Response.Redirect; however, I am unsure of how to clear the buffer to eliminate the html content being attached to the original Response buffer.
    Any suggestions?

  28. Avatar for Sam
    Sam December 5th, 2006

    An application contains a form where user enters his data like name address etc
    once the page is submitted it calls another page say nextPage.aspx. this page does not give any display info to the user but just process some data.
    so which of these will u use?

  29. Avatar for Srinivasan
    Srinivasan January 9th, 2007

    Good and informative!

  30. Avatar for Myrtle M Burton
    Myrtle M Burton January 20th, 2007

    Okay. I have spent hours on this issue I am experiencing. I gather I need to use server.tranfter in order to have the previous form's control values in the new page. But after the transfer, when the second page is diaplayed, the 'isnotpostback' condition is true. Which is fine and as expected. But When I click the submit button after the initial page is loaded, the isnotpostback is still true and only after the second time the submit button is clicked the isnotpost back condition is false. This would result on the user clickin the page again a second time and not acceptable.
    Furthermore, the second time the button is clicked the session variable set in the previous page is lost (even if cookieless is true) and only the session variables set in the second page is available after each postback on the new page. if the cookieless is set to false no session variables seem to retain the value.
    I need to retain session variables between pages.
    Any thoughts because I really am pulling my hair and questioning my sanity of wanting to write enterprise ready applications in
    Thank You in advance,
    - Myrtle

  31. Avatar for Jaichandran
    Jaichandran April 22nd, 2007

    What is 302?
    I heared If we use server.transfer we can customize as 200 to 401, Is it possible? Please explain me.

  32. Avatar for Haacked
    Haacked April 22nd, 2007

    The 302 status code is explained here.
    To set the status code, use something like this:
    Request.StatusCode = 302;

  33. Avatar for Tom's Blog
    Tom's Blog April 23rd, 2007

    Response.Redirect vs Server.Transfer Response.Redirect vs Server.Transfer .

  34. Avatar for G. Prahant Kumar
    G. Prahant Kumar June 3rd, 2007

    good explanation of R.D(),S.T()....informative

  35. Avatar for G. Everson
    G. Everson July 9th, 2007

    Thanks very much for the clear explanation, especially about clearing the Response buffer. I was having my form from the start page showing up on the transferred to page until I cleared the buffer.

  36. Avatar for billie
    billie July 12th, 2007

    Thanks was very helpful! Solved my problem rightaway.

  37. Avatar for oyunlar
    oyunlar September 9th, 2007
  38. Avatar for vikram pratap
    vikram pratap September 17th, 2007

    Response.Redirect send a message to the browser Saying move into another page while Server.Transer does not send any message to Browser it's redirect to another Page.
    Server.Transer there is no round trip. while response.Redirect has around trip and hence puts aload on Server.

  39. Avatar for Ashutosh
    Ashutosh October 21st, 2007

    Very nice article, can you tell us about what happens with server.transfer in terms of HTTP headers.

  40. Avatar for Parikshit Sehgal
    Parikshit Sehgal October 31st, 2007

    Thanks for easy and perfect explaination...You rock buddy !!!

  41. Avatar for Nigger
    Nigger January 31st, 2013