Web developers are constantly searching for ways to design and implement sites that deliver the best user experience possible. One way to enhance user experience is to customize content based on capabilities that the client browser supports. For example, when a client-side script detects a low-bandwidth modem connection to the server, it may choose to request low-resolution images from the server to minimize bandwidth consumption.
Client capabilities consists of information about the browsing environment, such as screen resolution, screen dimensions, color depth, CPU, or connection speed. Microsoft® Internet Explorer 4.0 exposed client capabilities as properties through the Dynamic HTML (DHTML) Object Model. Internet Explorer 5 enhanced this further to include a means to install browser components on demand. Beginning with Internet Explorer 5, all this information was encapsulated into DHTML behaviors and made available as one of the browser's default behaviors.
By making this information available on the client, pages can be cached, server roundtrips minimized, server resources freed up as content generation shifts back to the client, and overall performance improved.
This article outlines the benefits introduced by a client-side solution and discusses the details involved in obtaining client capabilities information from the client. Realizing that a client-side solution is not suited for every Web site or Web application, a solution for server-side developers is also provided.
Benefits of a Client-Side Solution
Before the release of Internet Explorer 4.0, the only means of obtaining client capability information was through cookies. Microsoft Internet Information Server (IIS) provided another mechanism through the Browser Capabilities component. However, these two methods have inherent limitations. By exposing client capabilities on the client side, Internet Explorer 4.0 provides a solution that attempts to overcome these limitations.
Using Cookies
The following diagram illustrates what occurs when the user types in the URL of a site that requires client capabilities.
| 1) The client sends a request to the server. | 1) The client sends a request to the server. |
| 2) The server sends back a script to obtain the information. | 2) The server sends the page, including a client-side script, to obtain the information. |
| 3) The client executes the script and stores the information in a cookie. | 3) The client executes the script and renders the page. |
| 4) The client sends the cookie back to the server. |
| 5) The server processes the information in the cookie and generates a custom page. |
| 6) The server sends the custom page back and the client renders it. |
The following table outlines the limitations to the server-side approach that uses cookies, and explains how these problems are addressed by a client-side solution that uses client capabilities.
| Server-side limitation | Client-side solution |
|---|
| Every time new client capability information is sent in a cookie as part of the client's request, the server spends precious cycles generating content for that client request. | By providing client capabilities on the client side, no cookies have to be passed back and forth. All the processing takes place on the client computer, none takes place on the server. This provides the server with more time to service other clients' requests. |
| Because the server generates a custom page for every client request, the page cannot be cached. | Client capabilities provides a way to shift the content generation process from the server back to the client. Because the server sends the same page for every client request for the same URL, the page is cached. Every subsequent client request for the same URL, therefore, can be serviced directly by the cache, rather than by an expensive roundtrip back to the server. |
| In a multiuser environment, where Internet requests are routed through a proxy server, the limitation is even more apparent. Consider the same scenario with 1,000 users. If every one of those users request the same page at least two times, the server has to respond 2,000 times to service each of those requests, because the page uses cookies and therefore cannot be cached on the proxy. | Because the client-side solution allows the page to be cached, the only time the proxy hits the server is the very first time a user requests the page. Every subsequent request for the same page is serviced directly by the proxy's cache, instead of the server. Consider the same environment of 1,000 users. This means one request instead of 2,000 requests. This represents a significant reduction in the number of server hits and results in increased performance on both the client and the server. |
Using the Browser Capabilities Component
The server-side Browser Capabilities component in IIS provides information about the capabilities supported by the browser by comparing the user-agent HTTP Header with the entries in the Browscap.ini file. Server-side scripts are then able to deliver customized content based on this information. However, this approach poses limitations as well. The following table outlines how client capabilities addresses these limitations.
| Server-side limitation | Client-side solution |
|---|
| The component relies on a file called Browscap.ini, which contains a static list of client capabilities based on the version of the browser. Due to the static nature of this file, it is updated every time a new version of the browser becomes available. | Exposing client capabilities on the browser works around this by making the same information available dynamically as part of the object model and accessible through script. |
| The static list maintained in Browscap.ini fails to account for options that the client can turn on or off on demand, nor does it provide version-independent information, such as whether certain components currently are installed on the client's system. | Among the types of information client capabilities provides are screen resolution, screen dimensions, available bandwidth, cookies or Java support, color depth, language, as well as components currently installed on the client. |
Obtaining Client Capabilities
As highlighted in the preceding section, the ideal way to obtain client capability information is from a client-side script. This method minimizes server roundtrips, frees up server resources, and, consequently, boosts performance.
Internet Explorer 4.0 introduced this type of information as a set of enhancements to the DHTML Object Model, making it easily accessible to client-side scripts. In most cases, this information has been exposed as properties of the navigator object, which contains information about the browser. In other cases, the information is available as properties of the screen object.
The following table outlines the client capabilities exposed since Internet Explorer 4.0.
Sample Code
The following example downloads the appropriate image based on the number of colors supported by the client screen. If it detects fewer than 256 colors (or 8 bits per pixel), it displays an image of 16 colors; otherwise, it displays a higher resolution image. As a result, the colors are more suited to the client screen, and overall user experience is improved.
<IMG ID="myImage" WIDTH=200 HEIGHT=200>
<SCRIPT>
{
if (window.screen.colorDepth >= 8)
myImage.src = "256color.bmp"
else
myImage.src = "16color.bmp";}
</SCRIPT>This feature requires Microsoft® Internet Explorer 4.0 or later. Click the following icon to install the latest version. Then reload this page to view the sample.
As of Internet Explorer 5, client capabilities information has been available as one of the browser's default behaviors. Encapsulated in this behavior are all the properties exposed in Internet Explorer 4.0, plus a set of new properties and methods that enable Web applications to install browser components on demand. For a complete list of properties and methods included in the clientCaps behavior, see clientCaps.
The following example shows how to use the clientCaps behavior to obtain some of the available client capabilities information. For more information about behaviors and using behaviors on a page, see Related Topics.
This feature requires Microsoft® Internet Explorer 4.0 or later. Click the following icon to install the latest version. Then reload this page to view the sample.
The Server-Side Approach
Note This requires IIS 5.0.
Although the benefits are clear, a client-side solution might not be viable for every Web application. In some cases, a Web developer might be locked into a server-side solution, and the disadvantage of using cookies might be negligible. For those cases, Internet Explorer 5 and IIS 5.0 introduce a way to access client capability information from a server-side script, using a combination of cookies and the IIS Browser Capabilities component. As of IIS 5.0, the Browser Capabilities component has been extended to include client capability information as properties of the component.
Because the information is available on the client, accessing the information from a server-side script requires a few more steps.
Implementation Details
Here are the steps required to obtain client capability information from a server-side script.
- Create a file that contains the client-side script to retrieve the client capability information on the server's behalf.
- Cut and paste the following code to your file.
Notice how the property names and their corresponding values are constructed as an ampersand-delimited list of name=value pairs. Persisting information as name=value pairs is characteristic of cookies. For more information, see cookie.
- Add as many name=value pairs as the number of client capabilities you need. When specifying name=value pairs, the property names specified on the left side of the equal sign do not need to match the names of the actual property in the DHTML Object Model. This specified property name is then used in step 2.c. below when the property is accessed from the server-side script.
- The BrowsCap cookie is set to the resulting string of all the name=value pairs.
- Once the cookie is passed back to the server, the Browser Capabilities component parses the string to find the values of individual properties from the cookie. These values are then accessible to the server-side script as properties of the component.
- Create a new Active Server Pages (ASP) file or modify an existing one.
- Insert the following METADATA tag as the first line in your ASP file. Make sure you set the SRC attribute to the name of the file you created in step 1. This file contains the client-side script to execute.
<!--METADATA TYPE="Cookie" NAME="BrowsCap" SRC="InsertNameHere.htm"-->
- Create an instance of the Browser Capabilities component.
There are two ways to do this. One way is to insert this object tag into your page.
<OBJECT ID=myBrowsCap PROGID="MSWC.BrowserType" RUNAT="Server"></OBJECT>
Another way is to call the CreateObject method of the Server object in ASP, and assign it to the variable myBrowsCap.
<% Set myBrowsCap = Server.CreateObject("MSWC.BrowserType") %> - Once the Browser Capabilities component is created, all client capability information retrieved from the preceding client-side script is accessible as properties of the component.
<%
Response.write("width= " +myBrowsCap.width + "<br>")
Response.write("height= " +myBrowsCap.height + "<br>")
Response.write("availHeight= " +myBrowsCap.availHeight + "<br>")
Response.write("availWidth= " +myBrowsCap.availWidth + "<br>")
Response.write("bufferDepth= " +myBrowsCap.bufferDepth + "<br>")
Response.write("colorDepth= " +myBrowsCap.colorDepth + "<br>")
Response.write("cookies= " +myBrowsCap.cookies + "<br>")
Response.write("javaapplets= " +myBrowsCap.javaapplets + "<br>")
Response.write("cpuClass= " +myBrowsCap.cpuClass + "<br>")
Response.write("platform= " +myBrowsCap.platform + "<br>")
Response.write("systemLanguage= "+myBrowsCap.systemLanguage + "<br>")
Response.write("userLanguage= " +myBrowsCap.userLanguage + "<br>")
%>