By Mark Gibbs
Network World, 5/25/98

Even if you've established intranet standards, you'd be wise to make sure your servers can identify what type of browsers are requesting information and can deliver content to them accordingly.

With browser sensing, if a nonapproved browser attempts to access content, the server can block the request and deliver a warning to the user.

On more open intranets, sensing can ensure that HTML 3.2 browsers don't choke when they come across nonstandard features, such as the layers option Netscape Communications Corp. offers in Communicator 4.01. A server would deliver different content to the HTML 3.2 browser than it would to the browser capable of viewing layers.

You also can use browser identification to prevent access by spiders, which are robots that explore Web server content. Spiders degrade performance if run indiscriminately by intranet users. Netscape's Navigator 4.0 and Microsoft Corp.'s Internet Explorer 4.0 use this type of functionality in their "push" implementations.

Implementing browser sensing requires some programming. You need a program that lets the server determine the browser type and a program that then lets the server act appropriately.

Client-side identification relies on the Web browser's ability to execute Java applets, VBScript or JavaScript, and requires recoding for each new browser release. We'll concentrate on the less complex server-side technique.

In server-side sensing, the browser announces its identity in the HTTP header it sends to the server when requesting a Web page. Let's examine one such header:

GET /company/aboutus.html HTTP/1.0

Accept: www/source

Accept: text/html

Accept: image/gif

User-Agent: Mozilla/4.04 [en] (WinNT; I)

The string following User-Agent: is the data the browser sends to back-end scripts via the Common Gateway Interface (CGI). Scripts read this string through the environment variable "HTTP-USER-AGENT."

If you are using a server API such as Netscape Server API (NSAPI) or Microsoft's Internet Server API (ISAPI), the browser retrieves the User-Agent string through API calls. No matter which way your application gets the User-Agent string, it won't find a fixed layout -there's no standard for formatting the data in the User-Agent string. In general, browsers list an identifying name, their version, then platform details in parentheses. But because there is no standard, you've got to know the User-Agent string for each browser you want to identify.

In the header above, the identifying name is "Mozilla'' and the version is "4.04.'' Netscape began using the identifying name Mozilla when it launched Navigator. Many browsers now use the Mozilla name in their User-Agent string to denote compatibility with Navigator. You could identify generic Netscape compatibility by looking for this name in the header.

The User-Agent string's nonstandard layout also is problematic because it tells you little of what the browser can do. If you want to send content that depends on the browser, you'll need to reference a database of browser capabilities.

Microsoft is a good resource for this information. The Active Server Pages (ASP) technology that comes with its Internet Information Server Web server software lets developers combine multiple programming languages to create dynamic content. ASP recognizes browsers and enumerates their features.

Microsoft stores this data in its browscap.ini database. You can download the latest version of this file from backoffice.microsoft.com Its structure is straightforward, but too lengthy to cover here. We'll leave you to the decoding (the ASP books listed in the margins should help).

Once you know the browser, you can return the content requested or redirect the browser to alternative content areas. The latter is done using the redirect HTTP header. If you just want to block nonsanctioned browsers, you simply look for User-Agent strings in a list of acceptable releases. If the string is not in the list, the server returns a warning rather than the page requested.

The server-side sensing application's design depends on your objective. For example, if performance is a consideration, you may only want to check access requests to browser- dependent content. If you need to check all requests, NSAPI or ISAPI would be better than CGI. Heavy use of CGI can hinder performance.

Server-side identification is worth the work. It provides a robust mechanism for enforcing the use of specific browsers or delivering the correct content to specific browser versions.