HttpBrowserCapabilities - Half The Story, Still Painful, Why I Still Dislike Browscap.ini
In the latest MSDN Magazine, George Shepard writes about determining whether or not a browser supports certain properties (”The ASP Column: Determining Browser Capabilities in ASP.NET”, Jan 2005). While I think the HttpBrowserCapabilities class is a great improvement over the classic ASP methods, I still think that determining support is not going far enough, and its archaic reliance on browscap.ini makes its use impractical in the long run.
Let me explain the first point, which I touched on in a previous blog post (“Don't sniff browsers--sniff objects“). If you need to determine whether or not a browser supports a certain property, it's obviously important to your needs. In the past, we've had to detect support for JavaScript, 128 bit encryption, and document.all vs. document.layers, all for very good reasons. Astute readers have just had a thought similar to “just because a browser supports JavaScript doesn't mean the user has it enabled”, and that's my point exactly. So what if a browser supports JavaScript? If the user has JS disabled, and you're relying on the idea that JS is supported, your scripts will not work. With ad blockers that strip out HTML code before it reaches the client browser, security centers that lock down any number of settings, and generally screwed up client machines, you can't really be sure what should be there actually is.
Secondly, the browscap.ini file. If you have the freshest version, it's not bad. But it doesn't take long before new browser versions render it out of date. If you're running IIS 5 on Win 2K, unless you've taken the time to track down a new version, your browscap.ini hasn't been updated since 2000. Your file is missing IE 6, FireFox, Mozilla and all the WAP enabled smart devices we were dreaming of almost 5 years ago. You can find updated versions (such as http://www.hpcfactor.com/developer/browscap/default.asp), but they suffer from the usual version conflicts when multiple independent sources are involved. You can update it yourself, but best of luck keeping on top of what you need to.
Remember for a time, after IE 6 was released? NS 4.7 and IE 5.5 were the major browsers. I ran into a great number of poorly written browser sniffers that read the USER_AGENT and MAJOR_VERSION, determined that my browser was neither NS 4.x nor IE 5, and alerted me to upgrade to a more modern browser. Nothing says “I'm clueless“ like telling someone with the latest browser they need to “upgrade“ to the older version.
The best way to determine support for what you need is to actually test for the creation and presence of objects and methods. This takes some client-side scripting, but it's not hard. And you'll have a definitive answer. I reference a good example in my previous blog post listed above. No guesswork, and it's actually much easier, and much more flexible. If you encounter a browser not listed in the browscap.ini, you will know if it supports what you need, and that client will be able to take advantage of the richer and more advanced features of your website.
For small needs, a small amount of client-side scripting will probably be sufficient. But, if you have needs for advanced detection, check out BrowserHawk ate http://www.browserhawk.com.