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.

Read more: dynaTrace

Posted via email from .NET Info