Application Security Testing: An Integral Part of DevOps
Callback and Controls Rendering (Manual Partial Page Rendering)
Why Should I Read this Article?
Callback doesn't cause postback and page rendering, either full nor even partial. You can communicate with the server (IIS) and your server side code runs there successfully. You could rebind your controls, such as Dropdownlist, Gridview, Listview, Datalist, Repeater, or any server-side control to which you assign data. However, the problem is when the page won't render, its controls won't render; if controls won't render, changes won't reflect. When changes won't reflect, there won't be anything at the front end to show on the web page.
First of all, I would like to brief you on some terms that I believe every web developer should be aware of.
Postback is a mechanism of communication between the client side (browser) and the server side (IIS). Through postback, all contents of the page/form(s) are sent to the server from the client for processing. After following the page life cycle, all server-side contents get rendered into client-side code and the client (browser) displays those contents. Callback is another way of communication between the server and client. Callback doesn't follow the page life cycle that followed standard postback and doesn't even cause Rendering.
If rendering won't happen, the changes won't reflect; this happens on the server at the client side. Ajax leverages partial postback automatically, whereas callback doesn't cause it, so a programmer needs to perform that task manually.
The ASP.NET team has created a RenderControl method with each control. By using that control, you can render your control very easily.
CALLBACK is a lightweight process. It uses the well-known xmlhttp object internally to call a server-side method. It doesn't cause page postback, so it doesn't cause page rendering. To show output at the client side, you need to make the output HTML yourself and render the controls manually.