Performing Browser Detection Using ASP.NET
By Scott Mitchell
Introduction
When the browser wars were at their height from 1996-1999, or so, browser detection was an important facet of Web design. During these years, the features supported by Microsoft and Netscape varied quite a bit, and Web designers who wanted to make use some of the "cooler" features of a given browser would need to detect what browser the user was using in order to customize the HTML outputted by the Web page. Many sites actually maintained two sets of pages: one for Netscape and one for Internet Explorer, and the main page would redirect the user to the applicable set of Web pages based on the user's browser.
To accomplish this, Web designers used what is known as browser detection. Browser detection, as its name implies, is detecting what browser a Web visitor is using. This is possible because Web browsers, when making an HTTP request to a Web server, pass in their HTTP headers a string referred to as the User-Agent, which specifies what browser type is being used. From a server-side Web page, one can easily determine the value of this HTTP header. In ASP.NET (or classic ASP), for example, one can display this parameter using the following line of code:
Response.Write(Request.ServerVariables("HTTP_USER_AGENT"))
|
Specifically, your Web browser has sent the following User-Agent HTTP header:
CCBot/2.0 (https://commoncrawl.org/faq/)
The User-Agent, unfortunately, is a bit cryptic, and requires parsing to determine what browser, specifically, a visitor is using. Furthermore, it doesn't contain information like what version of JavaScript the browser supports, or if the browser supports CSS 2.0 stylesheets.
Fortunately, ASP.NET provides a HttpBrowserCapabilities
class that performs all the parsing
of the User-Agent HTTP header to determine what browser the visitor is browsing with. By knowing
what browser the visitor is using, this class can also determine what properties the browser can
support (CSS support, JavaScript version, etc.). In this article we will examine how to use the
HttpBrowserCapabilities
class to perform browser detection in an ASP.NET Web page!
First Off - Does Browser Detection Matter Anymore?
One of the primary motivations behind browser detection in the late 1990s was to be able to direct users to an appropriate set of Web pages that has been customized for their particular browser. Today, however, you will rarely find Web sites that have separate pages for different browsers, in large part because Microsoft's Internet Explorer has come to dominate the browser market landscape. Also, as Web designers from the late 1990s can attest to, maintaining multiple sets of Web pages can be expensive and time-consuming. A smarter approach to Web design is to limit the features used to those that are supported by the vast majority of your expected user base. That is, refrain from the whiz-bang features that are only supported well in one particular browser, and stick to the plain ol' vanilla HTML. (Have you ever noticed that the Web's busiest Web sites - Yahoo, Amazon.com, Ebay, etc. - all use very simply HTML design that is renderable with the same look and feel on nearly every browser available?)
So why would one want to do browser detection anymore? One possible reason might be for browser exclusion. Typically, large corporations standardize on a particular browser, say IE 5.5, which they require installed on all corporate computers. Hence, the corporation's intranet expects only one type of browser, and the Web designer can take full advantage of features that he or she knows to be in that browser that might be lacking from older versions. Therefore, on a corporate intranet, if someone visits with a non-standard browser (be it a different browser or an older version of the accepted browser), you might wish to direct the user to a page explaining that the use of the intranet requires the corporation's standard browser.
Additionally, when Web search engines index a site they send a "crawler" to visit the various pages of your site and add them to their database. (This crawler is really just some script making HTTP requests to your page.) Typically these crawlers use a User-Agent string that indicates that they are crawlers (and not live users). In such a case, you may wish to serve up different content. For example, if you have a Web page that, whenever visited, performs a lengthy database call to display rapidly changing dynamic data, you may wish to show some cached version of the data when a crawler comes by. You may opt to do this in order to save the burden of having to run the query for a visitor that is not, after all, a real visitor.
Browser Detection in Classic ASP
In classic ASP there was four ways to perform browser detection:
- Using client-side script
- Using the User-Agent server variable
- Using the Browser Capabilities component
- Using a third-party program
The first technique uses client-side JavaScript to determine the browser version, and can also be
employed in an ASP.NET Web page. The second technique references the User-Agent HTTP header, as discussed
earlier, which can also be done in an ASP.NET Web page by accessing
Request.ServerVariables("HTTP_USER_AGENT")
. The third technique involves using a COM component
that shipped with classic ASP, MSWC.BrowserType
. Finally, the fourth technique involves
using a commercial product like CyScape's
Browserhawk.
These four methods are examined in detail in an earlier article of mine, Obtaining your User's Browser Information. If you are interested in learning more about browser detection with classic ASP, be certain to read that article.
Performing Browser Detection in ASP.NET
As aforementioned, in ASP.NET you can use client-side JavaScript for browser detection or direct examination of the User-Agent HTTP header. However, ASP.NET provides a much simpler way to determine browser information: the
Request.Browser
property, which is an instance of
the HttpBrowserCapabilities
object. The BrowserCapabilities
object contains
properties that describe the features available in a particular browser. These properties,
which are enumerated in the
technical
documentation, include:
ActiveXControls
- a Boolean, indicating if the browser supports ActiveX controlsAOL
- a Boolean, indicating if the browser is an AOL-supplied browserCookies
- a Boolean, indicating if the browser supports cookiesCrawler
- a Boolean, indicating if the browser is a Web search engine crawlerFrames
- a Boolean, indicating if the browser supports framesJavaApplets
- a Boolean, indicating if the browser supports Java appletsMajorVersion
- the browser's major version. The major version of IE 5.3 would be 5.MinorVersion
- the browser's major version. The minor version of IE 5.3 would be 3.Platform
- a String that specifies the user's computer platform, such as WinNT, Win95, UNIX, etc.VBScript
- a Boolean, indicating if the browser supports client-side VBScript code
Note that these Boolean values specify whether or not the browser can support such features. For example,
IE 6.0 has cookie support; therefore, if you want to check to see if a user's browser supports cookies using
the Request.Browser
property, a value of True will be returned for any user using IE 6.0.
However, users can configure their browsers so that they do not accept cookies; regardless of the user's
configuration, the Cookies
property will always return True if the user's browser has the ability
to support cookies.
The following code sample shows code that will display many of the properties of the user's browser.
|
What's Happening Behind the Scenes
As discussed earlier, the only way for the Web server to know what type of Web browser a visitor is using is by the User-Agent HTTP header sent by the browser. This string, as was shown, is quite simple, and you may be wondering how in the world ASP.NET can determine what features a particular browser can support just by this simple User-Agent string.
The answer is, it can't - it relies on information in the machine.config
file that specifies
what properties each of these browsers supports. The machine.config
, which can be found
in the directory $WINDIR$\Microsoft.NET\Framework\v1.0.3705\CONFIG
, is an XML-formatted
configuration file that specifies configuration options for the machine. This file contains, among
many other XML elements, a browserCaps
element. Inside this element are a number of other
elements that specify parse rules for the various User-Agents, and what properties each of these
parsings supports.
For example, to determine what platform is used, a filter
element
is used that specifies how to set the platform
property based on what platform name is found
in the User-Agent string. Specifically, the machine.config
file contains:
|
That is, if in the User-Agent string the string "Windows 95" or "Win95" is found, the platform
property is set to Win95
. There are a number of filter
elements in the
browserCaps
element in the machine.config
file that define the various
properties for various User-Agent strings.
Confused by the filter Elements? |
---|
The filter elements use regular expressions to match various pieces of the User-Agent string
with various supplied substrings. If you are not familiar with regular expressions, consider reading:
An Introduction to Regular Expressions.
|
Hence, when using the Request.Browser
property
to determine a user's browser features, the user's agent string is matched up to particular properties
in the machine.config
file. The ability for being able to detect a user's browser's
capabilities, then, is based upon the honesty in the browser's sent User-Agent string. For example, Opera
can be easily configured to sent a User-Agent string that makes it appear as if it's IE 5.5. In this
case from the Web server's perspective (and, hence, from your ASP.NET Web page's perspective), the user is
visiting using IE 5.5, even though, in actuality, he is using Opera.
Conclusion
In this article we have seen how to perform browser detection using ASP.NET. The technique of using the
Request.Browser
property is much simpler than parsing through the User-Agent HTTP header by hand.
Additionally, it is easier to use than classic ASP's BrowseCap COM object, which required instantiation of
a COM component.
Happy Programming!