Looking deep inside PostBack and ViewState in ASP.NET 3.5

Introduction

ASP.NET helps in the rapid development of web forms in a way similar to our Windows counterpart writes code to develop Windows applications for the desktop. Development is rapid in a Windows application for many reasons, i.e. there is no page life cycle, etc.

Major Difference between Windows applications and ASP.NET

Web applications are executed on the server, while Windows applications are executed on the client side. In a web application, users see web forms in a browser and provide inputs, which are posted back to the server. ASP.NET handles this GAP between the browser and the server by a technique called PostBack, which sends the page and all other user information to the server when a certain action is performed.
ASP.NET uses HTTP wire, which is Stateless for every round trip, and before the HTML output is rendered, all the user information and web page control objects are destroyed. Although this is good for avoiding heavy traffic applications, it is challenging to maintain a seamless experience for users. So, to maintain a persistence state, ASP.NET uses a technique called ViewState.
Event Model Windows programmers have an upper edge when it comes to programming a rich event model, such as programming for mouse clicks, key presses, or any other low-level control interaction. However, when it comes to ASP.NET, client actions happen on the client side, and server processing takes place on the server. This means there is a certain amount of overhead involved in responding to events in ASP.NET.

ASP.NET Control Automatic PostBack

Description: The only option to send a page, both for HTML and ASP.NET, is to click a submit button. However, when a page is posted, ASP.NET fires another event. This model is extended in ASP.NET control with an Automatic Postback Feature. I.e. input control can fire different triggers, and server-side code can handle them immediately.
How it works: ASP.NET controls have the property AutoPostBack. If set to True, ASP.NET uses the client-side abilities of JavaScript to bridge the gap between the client-side and server side. It is set to False by default, so if we want optimum performance by not causing a change event.

What does ASP.NET do?

ASP.NET adds a javascript function to the rendered HTML page, "_doPostBack ()". When called, it triggers a postback, which posts the page back to the server with all information.
ASP.NET adds two hidden input fields that the _doPostBack() function uses to pass information back to the server. One is the ID of the control that raises the event, and the second is any other information.
```
<input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" />
```

_doPostBack() sets these values with the appropriate information about the event and then submits the form.

<script language="text/javascript">
// <![CDATA[
function __doPostBack(eventTarget, eventArgument) {
    var theForm = document.form1;
    theForm.__EVENTTARGET.value = eventTarget;
    theForm.__EVENTARGUMENT.value = eventArgument;
    theForm.submit();
}
// ]]>
</script>

ASP.NET generates _doPostBack() automatically.
The code inside this function grows as more AutoPostBack controls are added to the page.
Control whose AutoPostBack property is true is attached with the _doPostBack() method by onClick or onChange property.
ASP.NET automatically changes a client-side JavaScript event into a server-side ASP.NET event, using the __doPostBack() function as an intermediary.

Real Example

Say we have a List control whose AutoPostBack property is set to True. So it posts back automatically whenever the user changes the selection in the list, and the client-side onChange fires up. The browser then calls _doPostBack(), which sends the page back to the server.

<select id="lstCountry" onchange="__doPostBack('lstCountry', '')" language="javascript">
</select>

ASP.NET ViewState

How the ASP.NET page model works: Each time the page is posted back, it loses control of object information and other user information. As changes are made to the page by the user, the page is changed from its initial state. Traditionally, statelessness has been overcome with the use of simple cookies, session-based cookies, and various other workarounds.
What is View State: It is an ASP.NET integrated state serialization mechanism to keep a state of page controls in postback.
How it works: Just before page code has finished running and HTML has been rendered to send back to the client, ASP.NET examines all the properties of the controls and if any property has been changed from its initial value, ASP.NET makes note of it in name/value collection like Hashtable. Then ASP.NET takes these values and serializes them into Base64 String. The final string is inserted in the <form> section of the page as a new hidden field.

Benefits

Server resources are freed after each request.
More scalable.

Limitations

Because the view state is stored on the page, it results in a larger total page size.
ASP.NET uses view state only with page and control properties.
View state isn't a good place to store sensitive information that the client shouldn't be allowed to see.

Okay so it's some action time, we will do an exercise to actually see how ASP.NET serializes and de-serializes page view state and how it is stored in hidden input fields.

Step 1. Create an ASP.NET application.

Step 2. Add a label and button.

<div>
    <asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>
    <br />
    <asp:Button ID="Button1" OnClick="Button1_Click" runat="server" Text="Button" />
</div>

Step 3. Write a handler for Button1_Click.

protected void Button1_Click(object sender, EventArgs e)
{
    // Retrieve the view state string for the current web page using server-side
    string viewStateString = Request["__VIEWSTATE"];
    
    // viewStateString contains the view state information.
    // Convert the Base64 string to an ordinary array of bytes
    // representing ASCII characters.
    byte[] stringBytes = Convert.FromBase64String(viewStateString);
    
    // Deserialize and display the string.
    string decodedViewState = System.Text.Encoding.ASCII.GetString(stringBytes);
    Label1.Text = decodedViewState;
}

.NET

The view state string isn't human-readable — it just looks like a series of random characters.

When you look at the decoded view state string, you'll see something like this.

? -162691655dd-Text Hello, worldddd????4 ?????U?Xz?

Note. You can notice that the value is quite visible in this randomly generated string, so it's not advisable to store sensitive data in the view state.

What is View State Chunking?

Scenario: When the page size exceeds a specified limit, many firewalls and proxy servers won't allow the pages to pass. To overcome such a problem, we have a technique called View State Chunking, which automatically divides the view state into multiple fields to ensure that no hidden field exceeds a size threshold you set.

How to activate View State Chunking?

We need to add a few lines of code in the web.config file for the system.web element.

<configuration>
    <system.web>
        <pages maxPageStateFieldLength="1024" />
    </system.web>
</configuration>

So when we request a page that generates a view state size larger than this value, several hidden input fields will be created.

I hope you enjoyed this ride.

Cheers!