Andreas Grabner About the Author

Andreas Grabner has been helping companies improve their application performance for 15+ years. He is a regular contributor within Web Performance and DevOps communities and a prolific speaker at user groups and conferences around the world. Reach him at @grabnerandi

How ASP.NET PostBacks and Redirects Work

Last week I got the following two questions from one of our clients

  • “We use ASP.NET PostBacks but can’t find the PurePath for the request triggering the PostBack handler – any hints?”
  • “We see many ThreadAbortExceptions in our ASP.NET Application and we are not sure why they happen – are they expected?”

Time for a little blog that gives some internals on PostBacks as well as Redirects (which are commonly used in PostBack handlers).

What is a PostBack and how does it work?

It’s not my intention to write the 50th blog post about PostBacks – I’d rather recommend checking out the following links for more details on ASP.NET PostBacks and the ASP.NET Page LifeCycle. I am also not necessarily advocating PostBacks here either as there are other ways of implementing web applications (e.g.: ASP.NET MVC) – but – as the question came up I am sure many out there use this feature and may wonder how it works.

The important thing to understand is that a PostBack – as the name implies – POSTs data back to the current url. This allows ASP.NET Developers to implement PostBack code similar to event handlers in rich UI’s where you even get access to before/after values of controls.

In the sample application I use I have a MainForm.aspx page that displays a login control with a username and password field and a login button. When the user clicks the login button the data of the form elements is POSTed back to the server which ultimately calls the Login Button Click event handler. When a user therefore opens a browser and browses to my MainForm.aspx page and then clicks the login button we end up having 2 HTTP Requests to the same MainForm.aspx page. The second request responds with a different page, e.g.: Yes you are logged in or Authentication failed even though it goes to the same URL.

The following illustration shows my login button handler that takes the values POSTed to the MainForm.aspx page and checks whether the username/password combination is correct.

PostBack triggers Login Button Event Handler which does user authentication and redirects depending on logon success

PostBack triggers Login Button Event Handler which does user authentication and redirects depending on logon success

Also – depending on whether it is the initial page request or a PostBack you may want to execute different code. This can be done by checking the IsPostBack property on the Page objects. Remember our earlier example? The user basically requested the same url – MainForm.aspx – but obviously expects a different result for the 2nd request. The following illustration shows how to implement conditional code depending on PostBack or initial request:

Conditional Code depending on whether this is a PostBack or initial page request

Conditional Code depending on whether this is a PostBack or initial page request

The answer to the first question I received last week therefore is: Identify the 2 requests on the same initial URL. The following illustration shows how dynaTrace displays the individual URL’s that have been traced so far and how to actually drill to the PurePath for the PostBack request. We see the 2 requests to MainForm.aspx and the two corresponding PurePaths where the second is the one that reflects the PostBack request which ultimately calls our click handler:

Identifying the PostPack PurePath and spotting the click event handler

Identifying the PostPack PurePath and spotting the click event handler

What’s the difference between Response.Redirect and Server.Transfer?

You probably wonder what really happens after a PostBack. Are we now always staying on the same MainForm.aspx page? Or is there a way to redirect the user to a different url? ASP.NET offers two options (at least I am only aware of these two). There is the option of redirecting the user to a different URL or let the server transfer over to process a different URL.

Let’s go back to my example from above. My user logs in. In case the login is successful I want the user to get to his personalized site. In case the login was not successful I want the user to get back to the login page with an error displayed that the login was not successful. One option to redirect the user to a different url is to use Response.Redirect telling ASP.NET to redirect to a different URL. Technically – Response.Redirect actually sends an HTTP Redirect Response back to the browser causing the browser to request the new URL. This works great – but – it causes an extra roundtrip between browser and server. The following illustration (using the FREE dynaTrace AJAX Edition) shows the Network Requests between browser and server when browsing through the pages of my application. We can spot the redirects that the PostBacks cause by using Response.Redirect:

PostBack's causing an additional roundtrip between browser and server as it uses HTTP Redirects

PostBack’s causing an additional roundtrip between browser and server as it uses HTTP Redirects

My sample application redirects to the same URL but using a different url parameter to indicate which feature of the web site my user should see, e.g.: overview. It is easy to spot what is going on here. First we have the initial request to MainForm.aspx which displays the login dialog (because my user is not yet logged in). The PostBack on MainForm.aspx comes back telling the browser to redirect to MainForm.aspx?action?overview which is then requested by the browser. This behavior goes on for every interaction my user does – basically causing an extra roundtrip that should be avoided. It also causes many exceptions on the server – and that brings me to the second question I received: In order to do the redirect ASP.NET aborts the currently executing thread with a ThreadAbortException. So – whenever you use Response.Redirect – expect to see ThreadAbortExceptions (in case you use something like dynaTrace that actually gives you insight into these internal exceptions).

Fortunately ASP.NET offers a second option to transfer to a different page. Server.Transfer shortcuts the redirect by executing another page request with the new URL in your current ASP.NET thread. When changing my implementation from Response.Redirect to Server.Transfer I get rid of all HTTP Redirects. The following illustration shows what a PurePath that uses Server.Transfer looks like:

Server.Transfer executes transfered URL in same execution thread

Server.Transfer executes transferred URL in same execution thread

Conclusion

Make yourself familiar with internals of ASP.NET. If you use other frameworks such as ASP.NET MVC make sure you do enough research and reading on the options the framework gives you and how things work internally. It is important to save on unnecessary HTTP roundtrips as they can become really expensive for end-user browsing experience. As always, feedback and your thoughts on this topic are welcome.

Comments

  1. Thanks for this great article!

    One thought about using Server.Transfer:
    when used after a post request (like in your login example) it’s usually better to use Response.Redirect because then it’s possible to reload (F5) the following page without getting the “send post request again” message from the browser. (“redirect after post” pattern)

  2. thanks hubert. thats a good argument for using response.redirect.

  3. Great post!

    Thanks for sharing it!

  4. If the server crashes can you apply a server.transfer without losing any data? I know that there is a high availability of disaster recovery software out there. Is that what the intention of the software is? I guess I’m still a bit confused on the difference between the response.redirect and the server.transfer. Under what circumstances is it best to apply the response.direct?

  5. Marc-John Juliano says:

    Hubert, thank you for the awesome post. Great info about getting rid of http redirects. -Johnny Juliano

  6. Andrew Deniel says:

    Hi,

    This is a very informative article. Thanks for sharing your knowledge. I have findout few other links that also descrebed in a good way about (PostBack,_doPostBack

    and AutoPostBack).

    http://mindstick.com/Articles/50855cbe-657e-41fa-a7b2-7835cfa1dba2/?PostBack%20in%20ASP%20Net

    http://www.c-sharpcorner.com/uploadfile/2f73dd/what-is-postback-in-Asp-Net/

    http://www.codeproject.com/Articles/68371/Detecting-Refresh-or-Postback-in-ASP-NET

  7. IsPostBack is a property of the Asp.Net page that tells whether or not the page is on its initial load or if a user has perform a button on your web page that has caused the page to post back to itself.

    http://net-informations.com/faq/asp/ispostback.htm asp.net ispostback()

    walsh

Comments

*


2 + = seven