Archive, ASP.NET, aspNETserve
     

More Than You Ever Wanted to Know About HttpBrowserCapabilities

In ASP.NET the HttpBrowserCapabilities object easily allows you to determine which web browser your site’s visitors are using. This information is pulled from the User Agent data sent by each visitors web browser.

The HttpBrowserCapabilities object can tell you, for example, which version of Javascript the client’s browser supports. This is an interesting feature for this object to support, considering no major browser advertises which version of Javascript they support via their User Agent field. For browsers ASP.NET recognizes, it can assign reasonable values for HttpBrowserCapabilities. But what happens if ASP.NET does not recognize the client’s browser? I discovered the answer to this question can rather unexpectantly while working on aspNETserve.

Recently I was experiencing an issue with aspNETserve where pages were lacking their __doPostBack Javascript function. Normally ASP.NET automatically includes the __doPostBack method on pages were at least on control (or the page itself) has made a call to GetPostBackEventReference. No matter what I did, I could not get this method to be included on pages hosted within aspNETserve. To make a long story short, it turned out that when my code was parsing incoming HTTP requests, it was messing up the browser’s user agent field. For example, Firefox’s user agent would be transformed from:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

To:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv 1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

Notice the difference? Yeah, me neither… at least not at first. The latter user agent is missing a colon between "rv" and "1.8.1.4". Seems like a small enough mistake, but this small mistake was preventing ASP.NET from recognizing my browser as Firefox. The consequence of which was that ASP.NET did not think my browser could support Javascript, so therefore did not output any Javascript in the HTML it produced.

I have since fixed this issue in aspNETserve, and it now correctly outputs the __doPostBack method. What started as a frustrating attempt to get the __doPostBack method to be properly included for pages hosted within my ASP.NET web server, turned into a chance to better understand the inner workings of ASP.NET.

Never miss an article! Subscribe to my newsletter and I'll keep you updated with the latest content.

 

About Jason

Jason is an experienced Entrepreneur & Software Developer with a demonstrated history of working in the oil & energy industry. Skilled in Leadership, Mobile Development, Data Synchronization, and SaaS Architecture. Strong engineering professional with a Bachelor of Science (B.S.) in Computer Science from Arkansas State University.
View all posts by Jason →

Leave a Reply

Your email address will not be published. Required fields are marked *