Page #65 (Chapter 9 - Dealing with Multiple Browsers)

	Chapter 9 - Dealing with Multiple Browsers
	Visual Basic Developers Guide to ASP and IIS
	A. Russell Jones

Copyright 1999 SYBEX Inc.

---

	Determining Browser Type

	Browsers send an identifying string along with each request. The ASP page parses that into the ServerVariables collection under the key HTTP_USER_AGENT. For Internet Explorer 5, the string is:

	HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 5.0; Windows NT 5.0)

	For Netscape Communicator 4 for Windows 95, it is:

	Mozilla/4.0b1 (Win95; I)

	The string has plenty of information; how much of it you'll need depends on what you need to do. Differences exist not only between browsers and versions, but also between minor versions of each of the browsers (3, 3.1, 3.2, etc.). To make matters even worse, the capabilities of a specific version or sub-version differ between platforms: IE for the Macintosh is not exactly the same as IE for Windows 95, which is not the same as IE for Windows 3.1. Sometimes you need to know the exact browser version number, platform, and capabilities; other times you need to know only whether it's Netscape or IE. If you stick to standard HTML 3.2, you won't care at all as long as your HTML is well formed.

	At the most basic level, you can search the HTTP_USER_AGENT string to determine whether a browser is IE or Netscape.

	If instr(1, Request.ServerVariables("HTTP_USER_AGENT", _

    "MSIE", vbTextCompare) > 0 Then

......' browser type = IE

ElseIf instr(1, Request.ServerVariables _

    ("HTTP_USER_AGENT", "Netscape", vbTextCompare) > 0 Then

......' browser type = Netscape

	If you need to know more than just the browser type, you can use the MSWC Browser Capabilities component (browscap.dll) delivered and installed with Active Server Pages technology. The MSWC.BrowserType object maps the HTTP_USER_AGENT string to a set of entries in an .ini file (browscap.ini) that must exist in the same directory as the browscap.dll file. Microsoft maintains this file with help from many developers. You can download the latest copy of the browscap.ini file from many sites on the Web. The official Microsoft version is now at http://www.cyscape.com/browscap/, but other sites have browscap.ini files that are much more complete.

	When a BrowserType object finds one or more browser entries that match the string sent by the browser (more on that in a minute), the component finds the matching string in the browscap.ini file. The .ini file contains an associated list of properties for that browser, which the component then makes available to you as properties. Here's a sample entry from browscap.ini for an early version of Internet Explorer:

	[Mozilla/1.22 (compatible; MSIE 2.0c; Windows 95)]

parent=IE 2.0

platform=Win95

version=2.0c

	Note		An .ini file is a text file. It contains strings in brackets called sections. Each section contains zero or more entries. Each entry consists of a key and a value. Comment lines begin with a semicolon. In Windows 3.x, .ini files held application initialization and settings, hence the name .ini. Microsoft abandoned .ini files (mostly) starting with Windows 95. Windows now stores most application settings in the Registry. Nonetheless, Windows still contains the API functions to read and write data to .ini files.

	The section entries (in square brackets) correspond to the text sent by the browser in the HTTP_USER_AGENT variable. When the BrowserType object finds a matching string, it reads the parent entry if one exists—in this case, IE 2.0. The parent entry contains the list of base properties for that browser:

	[IE 2.0]

browser=IE

version=2.0

majorver=2

minorver=0

frames=FALSE

tables=TRUE

cookies=TRUE

backgroundsounds=TRUE

vbscript=FALSE

javascript=FALSE

javaapplets=FALSE

beta=False

Win16=False

	Individual browser sections can override or extend the base properties. For example, the base property named Win16 is False. There is a 16-bit Windows version of IE 2, though, so the entry for that browser overrides the base property value:

	[Mozilla/2.0 (compatible; MSIE 2.1;  Windows 3.1)]

parent=IE 2.0

platform=Win16

Win16=True

version=2.1

minorver=#1

frames=True

	If the BrowserType object can't find an exact match, it looks for wildcard matches. A wildcard section contains an asterisk. These sections are useful for matching browsers with only minor differences. For example, there were several minor differences between various NT versions of IE 3, so browscap.ini contains an entry that will match all of them:

	[Mozilla/2.0 (compatible; MSIE 3.0; Windows NT;*)]

parent=IE 3.0

platform=WinNT

	If the BrowserType object can't find any match, it looks for a default entry—a single asterisk that matches any browser. Here's a partial default entry listing:

	;Default browser

[*]

browser=Default

Version=0.0

majorver=#0

minorver=#0

frames=False

tables=True

	The BrowserType object searches the .ini file from top to bottom. It stops searching at the first match. Therefore, wildcard entries must appear after all other entries for that browser; otherwise, the BrowserType object will always find the wildcard entry first. Similarly, the default entry must be the final entry in the file.

	Almost all the entries expose these properties:

	•		Major and minor version numbers

	•		Cookies

	•		Frames

	•		VBScript

	•		JavaScript

	Other properties are exposed on a per-browser basis. You query the BrowserCap object's Capabilities property to find out whether the requesting browser supports these other capabilities.

	Using the Browser Capabilities Component

	In this project, you'll use the Browser Capabilities component to determine the capabilities of your browser. You can't add a reference to the MSWC.BrowserType component from VB, and you can't create a new BrowserType object in a normal way from inside a WebClass (although I'll show you how to do that in Chapter 11, "Using ActiveX DLLs from WebClasses"). For now, the easiest way to take advantage of the component is to use it in an ASP page. This requires mixing VB WebClasses with ASP pages—something that you haven't done yet in the projects in this book. Fortunately, you can mix ASP pages and WebClass "pages" with impunity because the WebClass (as you'll recall from Chapter 4, "Introduction to WebClasses") is just a COM component called by an ASP page. WebClasses and ASP pages share the same ASP objects (Session, Response, etc.) so you can pass information from ASP pages to WebClasses and back again in Session variables.

	The capability to mix ASP pages and WebClasses provides you the opportunity to put code that may change often (such as decisions about browser types) into a form that you can change easily. There's no code in the world that you can change more easily than an ASP page, because it's a text file, not a compiled and registered DLL.

	In this project, you'll call an ASP page that will instantiate the Browser Capabilities component and store browser properties in Session variables. Your WebClass can then read the properties from the Session variables.

	Start a new WebClass project. Name it BrowserCapProj. Rename the default WebClass to BrowserCapTest and set the NameInURL property to BrowserCapTest as well.

	Enter this code into the WebClass_Start event:

	Private Sub WebClass_Start()

    If Session("Browser") = "" Then

        Response.Redirect "getBrowserCapabilities.asp"

        Exit Sub

    End If

    Response.Write "<html><head></head><body>"

    Response.Write Request.ServerVariables _

       ("HTTP_USER_AGENT") & "<br>"

    Response.Write "Browser=" & Session("Browser") _

        & "<br>"

    Response.Write "Version=" & Session _

        ("BrowserVersion") & "<br>"

    Response.Write "Cookies=" & Session _

        ("BrowserCookies") & "<br>"

    Response.Write "VBScript=" & Session _

        ("BrowserVBScript") & "<br>"

    Response.Write "JavaScript=" & Session _

        ("BrowserJavaScript")

    Response.Write "</body></html>"

End Sub

	The WebClass_Start event code writes the HTTP_USER_AGENT header string, then checks the value of Session("Browser"). If the variable is empty, then it redirects the browser to an ASP page called getBrowserCapabilities. The ASP page creates an MSWC.BrowserType component and saves five values in Session variables. Here's the VBScript code for getBrowserCapabilities.asp.

	<% @ LANGUAGE = VBScript %>

<%

Response.Expires=-1

Dim objBrowsCap

Set objBrowsCap = Server.CreateObject("MSWC.BrowserType")

Session("Browser") = objBrowsCap.browser

Session("BrowserVersion") = objBrowsCap.version

Session("BrowserCookies") = objBrowsCap.cookies

Session("BrowserVBScript") = objBrowsCap.VBScript

Session("BrowserJavaScript") = objBrowsCap.JavaScript

Set objBrowsCap = Nothing

Response.redirect "BrowserCapTest.asp"

%>

	The last line of the ASP script redirects back to the original WebClass page, which will then run the WebClass_Start event again. If you step through the project with the debugger, that's exactly what you'll see. Figure 9.1 shows the output of the program for Internet Explorer version 5.

	Whether you need to use the Browser Capabilities component depends on how many types of browsers you expect to access your site and how polite you want to be. For many sites, searching the HTTP_USER_AGENT string tells you all you need to know. For example, if you only want to know whether the client browser is Internet Explorer, look for MSIE in the string:

	Dim isIE As Boolean

isIE = InStr(1, Request.ServerVariables _

    ("HTTP_USER_AGENT"), "MSIE", vbTextCompare) > 0

If isIE Then

    Response.Write "You're using Internet Explorer."

End If

	Now that you know how to determine which browser is accessing your application, you can determine how to respond.