Visual Basic Developer[ap]s Guide to ASP and IIS

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.
Related

Категории