Dealing with Wireless Browsers

By Kamal Patel 
February 20, 2001

Background

WML is a very good implementation of XML. The beauty of being an XML application is that extending the language is simply a matter of updating the DTD (Document Type Definition). This beauty also has a dark side associated with it. This dark side is that WAP specifications require that the vendors provide micro-browsers for a specific DTD on wireless clients. What does this mean? Well, when DHTML (Dynamic HTML) was added to the Microsoft’s Internet explorer we went to the right web site and downloaded the new browser, installed it and we were ready to go. Well, in wireless devices you are pretty much stuck with it… at least today.

Till date applications for the web are written browser specific. This is because one browser supports some features and others do not. This is even worse in case of WML Browsers. Some devices support WML1.1, some will support WML1.2 but no WMLScript, some will support WMLScript with WML1.1. Some vendors have added features to the language, specifications that are not yet recognized by the Wapforum, making the applications vendor specific now. The combination is simply too extensive.

Hence, in order to create wireless applications that work on multiple browsers, it becomes important to determine the type of browser being used and what is the device making the request. This article explains how we can determine the browser and device type.

Determining the Browser

When a browser sends a request for any content to a web server, the web server has a means to identify the browser through one of its headers. The web server can achieve this by accessing the HTTP_ACCEPT header that lists the content type supported by the browser. In ASP, we get the value of this header accessing the Request object’s ServerVariables(). Following is an example of how we use the HTTP_ACCEPT to determine if the request is coming from a regular browser or a micro-browser. We then redirect the request to the appropriate web site with either WML or HTML contents.

< %
‘Capture the ACCEPT string from the server variables
lcAcceptString = Lcase(Request.ServerVariables(“HTTP_USER_AGENT”))

‘Check if the ACCEPT string contains wml then redirect user to WML content
If InStr(lcAcceptString, “wml”) Then
        Response.ReDirect(“Index.wml”)
Else
        Response.Redirect(“Index.html”)
End If
% >

The above figure shows a sample HTTP_ACCEPT, listing the content type supported by that device. Using HTTP_ACCEPT to determine the browser allows us to create a single web site for WML and HTML clients.

Determining the Type of Device

Another means of getting more device information is through the use of HTPP_USER_AGENT. Unlike the HTTP_ACCEPT, which only returns supported content type, HTPP_USER_AGENT specifies more detailed information about the device and is more useful in differentiating among wireless devices. Again, HTPP_USER_AGENT is accessed the same way HTTP_ACCEPT is accessed; though the use of Request.ServerVariables().

Looking at the above image, we not only get the device type, in this case ERK0, but also the version of the browser and some other device specific data. Please note that the data for HTTP_USER_AGENT can differ significantly depending on the device and the micro-browser being used. You can find a list of user agent micro-browsers at http://amargo.g-art.nl/useragent.

Conclusion

Programming against user agents is a sad reality of life, at least today. With time, there will be more widely accepted common standards among devices and gateways. Currently the best approach to design WML applications is through the use of server side scripting technologies and applying XSLT templates to XML data for generating WML content.