Session is not missing in the Handler

I still remember the first time that I'm developing with generic handler (.ashx) and found out that the session is missing. This is because the handler implements only the basic feature (as compared to Page class).

In order for the AJAX call accessing the session information, your handler must implement the following interface:

    System.Web.SessionState.IRequiresSessionState

OR

    System.Web.SessionState.IReadOnlySessionState

That's all you need.

Posting data in JSON format to the ASP.NET website

When you are posting data using JQuery AJAX, you may call $.post() method to submit the data. We normally post the "data" by specifying the parameter name and value into the "data" parameter in the $.post() method. But, it will be very tedious to add new field to the data parameter when you already have lots of fields. To ease the coding maintenance, you may post the data in JSON format. This is quite simple by instantiating a new Object and set the property with values.

For example, I wrote this script in a HTML file:

    <script src="../Scripts/jquery-1.7.js" type="text/javascript"></script>
    <script type="text/javascript">
        function postJson() {
            var m = {
                myname: 'abc',
                myage: 10
                // add more properties here
            };
            var url = 'post_json.aspx';
            $.post(url, JSON.stringify(m), function (d) {
                if (d && d == 'ok') {
                    alert('ok');
                }
                else {
                    alert('failed');
                }
            });
        }
    </script>

Below is the "post_json.aspx" which you may use Handler (.ashx) to avoid the ASP.NET page life cycle.

using System.Web.Script.Serialization;

    public partial class post_json_post_json : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {      
            string json_text = this.Request.Form[0];
            JavaScriptSerializer js = new JavaScriptSerializer();
            CInfo my_obj = (CInfo)js.Deserialize(s, typeof(CInfo));

            this.Response.Write("ok");
            this.Response.End();
        }
    }

This is the data class that I'm using in this demo:

    public class CInfo
    {
        public string myname { get; set; }
        public int myage { get; set; }
    }

By using this technique, you will be achieving the following:

• Easy to maintain the JavaScript coding by replacing the data parameter in the $.post() with a stringify data in JSON format.
• Easy to maintain the code in ASP.NET - this is because you just need to declare a class which contains all the properties which is same as the data in JSON format. You may declare a property with other class type as well and also supporting object array.

Improving the web app by using AJAX + Handler

The following diagram explains the way to improve the web application response and reduces the server load by using AJAX call to the Handler.

For example, the "default.aspx" allows the user to post message and view all the messages. In the default.aspx, you will not use the GridView control to show all the messages. Instead, you make AJAX requests to the LoadMessage.ashx and show the result in the default.aspx. In this way, no viewstate and no ASP controls will be generated by LoadMessage.ashx.

The LoadMessage.ashx may return the result in 2 ways:

• formatted result (with HTML/TABLE tags or whatsoever) OR
• result in JSON format. Of course, the result in JSON format requies lesser bandwidth. But, you need to write some Javascript to format the result and show it in the default.aspx.

Another function provided by PostMessage.ashx will be a lot simpler. When the user type their message in the default.aspx (at the client site), you just need to retrieve the message from the screen and then make AJAX calls to the PostMessage.ashx (with the appropriate parameters).

Handler (ashx) VS Page (aspx)

We used to do development with Page (aspx) which comes with lots of rapid application development feature such as postback handling, drag & drop support, etc. But, this becomes expensive when the application is hosted in the Internet (not in a LAN). The viewstate, the control object instance generation, etc are all come with a price. A more complicated situation is that when you try to use AJAX (ScriptManager + UpdatePanel), the performance become questionable (when traffic goes up) and the coding become very complicated.

On the other hand, Handler (ashx) is a class that provides very basic functionality as compared to Page. There is no visual designer for Handler. No viewstate. No control object generation. No postback. You have to handle everything by yourself. The advantage of Handler as compared to Page is the performance (by giving up all the rapid application development features).

With JQuery and JSON, implementing AJAX become very easy. Modifying the DOM objects at the client site become easier as well. Using JQuery AJAX call to the Handler will boost up the performance because the viewstate is no longer require to transmit back and fore between the server and the client. At the server side, it also does not requires to re-generate all the control object instances.

Try this out:

• Design a data entry form in Page (aspx).
• Click on the Submit button and the client will make a AJAX call to the Handler (ashx) with the user input values.
• Then, the Handler will return the result in JSON format to the client.
• The client will then check the result and make the appropriate response.

 Benefits of using Handler (ashx) + Page (aspx):

• Faster response time
• Reduce the data to be transmitted between the server and the client.
• The server CPU load will reduce due to the Page call is lesser.

 Challenges:

• The developer requires to more JavaScript/JQuery knowledge.
• Harder to debug.
• Because the input controls in the Page is sometimes unpredictable (in .Net 3.5), getting the input field with JQuery will become troublesome.

Hosting images using Handler (ASHX)

In HTML, when we want to display images, we are using the following tag:

   <img src="images/myProfilePhoto.jpg"/>

That's very simple and has nothing much to complaint. But, you won't be able to trace who has requested the image file especially when the privacy issue comes into place... it becomes very nasty. In this case, we need to use ASP.NET Handler (ASHX) to host the images.

Advantage of hosting images through Handler:

• You can hide the image file path. For example, your web app is located in D drive and all image files are stored in E drive (where you don't have to expose the image folder in IIS).
• You may track down the visitor information that includes their IP address, browser, etc.
• You may stored the images in a database and host it through the Handler - you don't need to create an image file physically and then write the phyicsal file name into "SRC" attribute. You just need to set the SRC attribute to your ASHX handler (refers to the sample code in the link below).
• You may cache the images in the server.

In the HTML, you will have something like this:

  <img src="showPhoto.ashx?memberID=0001"/>

Where "showPhoto.ashx" is the Handler that you develop and "memberID" is the query parameter. Your handler should return the profile photo (in byte array) for member ID 0001.

For the code on how to implement the Handler or ASHX:

  http://stackoverflow.com/questions/994135/image-from-httphandler-wont-cache-in-browser
  http://stackoverflow.com/questions/1507572/streaming-databased-images-using-httphandler

For full explanations on the Handler:

   http://support.microsoft.com/kb/308001

Prevent the setting nested into sub-virtual directories

If you have a virtual directory which contains sub-virtual directories and you don't want the root virtual directory settings (in the web.config) to be inherited into the sub-virtual directories, you have to wrap the "system.web" with "location".

  <location path="." inheritInChildApplications="false">
    <system.web>
    ....
    </system.web>
  </location>

Looking for clue which website crash IIS

I have about 10 ASP.NET web applications running on the same IIS server. Somehow, I made changes to  "some" libraries and I could not figure out which web application keep crashing IIS server.

After many days in googling the solution, I found out that there is a freeware program which is able to open .WER file. Within this crash dump file, you will be able to find out which web application crashed your IIS.

   http://www.nirsoft.net/utils/app_crash_view.html

You will be surprise when you run this program because it will show all the crash dump files in your server/laptop.