Hack 87. Detect BlackBerry Browser Requests the Right Way

Examine the headers of an HTTP request to determine what content is best suited for the browser making the request.

Let's say you've decided to have different versions of the content on your web site for desktop browsers than for the BlackBerry Browser. What is the best way to make these versions available to your users? You could make the different versions available at different URLs. For example, http://www.site.com would be for regular browsers while http://wap.site.com would be your URL for WAP browsers. While this approach certainly works, it forces your users to remember two different URLs for essentially the same content. It would be more convenient to use a single URL for your site and have your web application determine the content that should be provided, depending on the browser making the request. How can you check to see what type of browser is making a request to your web application?

There is a right way and wrong (read: easy) way to do this in your application. The good news is that the wrong way is okay to do in certain situations. There are two different HTTP headers that are available to your web application to help determine the browser type: HTTP_USER_AGENT and HTTP_ACCEPT.

8.4.1. The Old Way

The HTTP_USER_AGENT,or user agent string, is used by browsers as a way of advertising their browser type. This string has information about that identifies the browser and version along with general details about your operating system. For example, the following string is what is presented to web servers by Firefox on my Mac:

 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050414  Firefox/1.0.3 

The traditional method of determining browser type is parsing this value for certain identifying strings, such as MSIE 6.0 or Netscape 4.73. Back in the days when web browsing was reaching the tipping point in the late 1990s, this type of detection of browser types was commonplace and even required in some circumstances because of the differing behavior of the major browsers. Each browser supported a unique subset of HTML tags and handled some tags differently than other browsers, so web developers worked around these idiosyncrasies by parsing the user agent and returning different versions by browser.

This approach could certainly be used to serve up appropriate content to BlackBerry Browsers by parsing the user agent string for the word "BlackBerry." Most web servers provide access to this field through an environment variable, so a simple Perl regular expression for doing this would be:

 if ($ENV{HTTP_USER_AGENT} =~ /BlackBerry/i) {         # we've got a request from a BlackBerry } else {         # regular browser } 

This method is fine if you're certain that you only want to support BlackBerry's handheld browser. The problem with this approach is that there are other handheld browsers that you probably want to support as well. When you decide you want to support another handheld's browser, you'll have to change the code in your web application to support it! When another handheld comes along, you'll have to make another change. Before long, your browser detection code in your web application is growing large and complex. As a software developer, you want to keep your code as small and efficient as possible.

8.4.2. A Better Way

A more effective long-term solution is to interpret the HTTP_ACCEPT header, also presented by a web browser with every HTTP request. It specifies what media types the browser is capable of interpreting as a response from the web server. The HTTP_ACCEPT header is a comma-delimited list of MIME types along with some optional parameters specified with each. For example, here is the HTTP_ACCEPT value that Firefox presents to a web server:

 text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;        q=0.8,image/png,*/*;q=0.5 

According to the HTTP specification, this HTTP_ACCEPT string means that the browser is capable of interpreting all the MIME types listed. In the case of text/html;q=0.9, the value of q is a way for the browser to indicate its preference if the server is capable of serving different types of content. Looking at all the text type in the HTTP_ACCEPT header, you can see that the browser is saying that it is capable of supporting content of type text; however, it prefers text of the XML variety since a nonexistent q parameter implies a q-value of 1. If text/xml is not available, then HTML is preferred (text/html;q=0.9), followed by plain text (text/plain;q=0.8).

If you have content tailored to a WAP browser, you can look for the following string to verify that the browser is capable of interpreting it: text/vnd.wap.wml. Look for the text/vnd.wap.wmlscript MIME type for browsers that support WMLScript (or at least claim to be able to).

By interpreting the HTTP_ACCEPT header and looking for a specific MIME type, you are not trying to guess the best content by first determining the browser type, but you're letting the browser tell you what content it handles best. This is a superior approach because you won't have to change your code when the next handheld browser comes along that you need to be able to support. That new browser will use the HTTP_ACCEPT header properly, and you'll already have it covered in your code.

This is the "proper" way for servers and web applications to do what is, in effect, browser sniffing. This technique wasn't possible a few years ago because of the browser shenanigans brought about by the browser wars between Microsoft's Internet Explorer and Netscape. Your web app could use the HTTP_ACCEPT header, but you still had to implement some way of determining the browser type because of the various quirks inherent with each browser. However, today's modern web browsers are fulfilling the previously unmet promise of a browser-agnostic web due in no small part to the browsers' support of Cascading Style Sheets [Hack #88].

8.4.3. See Also

• HTTP Specification http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1