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

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

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

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

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 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.

Related reading:

1. SharePoint: Performance Problem with LookupField Control The Microsoft.SharePoint.WebControls.LookupField control is used as the default control when editing...
2. SharePoint: List Performance – How list column indices really work under the hood Have you ever wondered what is really going on under...

• ComponentArt Releases the First True Controls for ASP.NET AJAX
• Upgrading the default ASP.NET MVC project with IoC and the Unity Controller Factory
• The Continuing Evolution of ASP.NET: An Interview with Scott Guthrie, co-creator of ASP.NET