Server-Side Browser Detection and Content Delivery : Mobile Detection (part 1) - HTTP

1/29/2011 6:44:27 PM
Before talking about detection of mobile devices and services on the server, we need to go back a bit and consider an old friend: the HyperText Transfer Protocol, also known as HTTP. Knowing a bit about its internals will help us determine what we can do in terms of mobile web development.


There are no special server requirements for mobile websites; you can just use the same Apache, Internet Information Server (IIS), or other server you are currently using for desktop websites.


HTTP is a protocol originally defined in 1991 for document transportation over TCP/IP networks. It has two main versions: 1.0 and 1.1 (the last and current version of the protocol, defined in 1996). This same protocol is the one that we need to use from the server side in mobile web development.

Actually, the last sentence isn’t strictly true if we consider WAP 1.1, where the device communicates with the WAP gateway and the WAP gateway is the one connecting to our server via HTTP. A similar approach is used in proxied browsers, like Opera Mini and Bolt (see Figure 1). However, from the server’s point of view the requests coming in will always be HTTP requests.

Figure 1. When the user is accessing our website via a proxied browser or a transcoder, we will not receive the request directly from the user’s mobile device.

1.1. The request

An HTTP request involves a client (the browser) sending a request to a server using its IP address (previously converted from a domain name). That request has a header and an optional body. The body is generally sent when we are doing a POST request. The most common request type is a GET, requesting a document or a file from the server.


Verizon uses an Optimized View enhancement (a transcoder) for mobile websites that are not on one of the mobile addressing standards (.mobi, wap., m., etc.). If you want to avoid transcoding of your site you can make an opt-out request at

The server responds with a response status code (hopefully not the famous 404), a header, and an optional (but generally sent) body. The body is the requested file.

Why are we taking this two-minute networking class? Because it illustrates many of the techniques we will use in server-side detection.

1.2. The request header

The request header has many attributes defined by the browser and sent to the server (if no proxy, gateway, or transcoder is in the middle). Some of the attributes that we will find useful are listed in Table 1.

Table 1. Most common HTTP request headers
User-AgentThe name of the browser or platform that originated the request
AcceptA comma-separated values (CSV) list of MIME types accepted by the browser
Accept-CharsetA CSV list of charsets accepted by the browser (e.g., ISO-8859-1, UTF-8)
Accept-LanguageA CSV list of preferred languages in the browser
Accept-CharsetA CSV list of compression methods available for the response (e.g., gzip, deflate)


Every mobile browser supports HTTP authentication, showing a modal window for username and password entry so the user can log into the website.

The following is the header of a real request from a mobile device to a server:

GET / HTTP/1.1
Accept: application/vnd.wap.wmlscriptc, text/vnd.wap.wml,
application/vnd.wap.xhtml+xml, application/xhtml+xml, text/html, multipart/mixed, */*
Accept-Charset: ISO-8859-1, US-ASCII, UTF-8; Q=0.8, ISO-10646-UCS-2; Q=0.6
Accept-Language: en
DRM-Version: 2.0
Cookie2: $Version="1"
Accept-Encoding: gzip, deflate
User-Agent: Nokia5300/2.0 (03.50) Profile/MIDP-2.0 Configuration/CLDC-1.1
x-wap-profile: ""


Many mobile browsers send */* as the list of accepted MIME types to avoid the server prefiltering the content that it can deliver using the Accept header. Other mobile browsers have known bugs in the MIME type lists that they provide.

1.3. The user agent

The user-agent string identifies the browser. It has had a complex history, with the result that today there are browsers that identify themselves as six different browsers at the same time in the same string. This somewhat complicates browser detection. There is an excellent history of the user-agent string, presented in a very funny way, at

In brief, as in the beginning of the web era developers often looked for a particular string in the User-Agent header to determine what content to deliver, many browsers, starting with Microsoft Internet Explorer, started using a hack that today has resulted in user agent hell. The hack was for Internet Explorer to identify itself as Mozilla (the way that the Netscape browser, IE’s main competitor, was identified). After this initial identification, it clarified that it was not actually Mozilla, but rather a compatible browser (IE). Microsoft also added other information to the user-agent string, like the operating system and details on the plug-ins and languages supported. The end result was a very complex user agent syntax with no standards.

In the mobile world, the situation is even worse. Some browsers use the IE hack and identify themselves as Mozilla (with some clarification), others identify themselves with the correct browser name, and still others send the device brand and model number in the User-Agent header. Even the same device may provide a different user-agent string depending on the OS version or the firmware used. This makes device detection using this string a bit complex.


If you don’t want your site to be transcoded, you can use Cache-Control: no-transform both in the HTML document and in the HTTP headers. Some transcoders use this information to decide whether or not to transcode a document, but there is no guarantee that this will work.

The following is a list of some mobile user-agent strings provided by a Nokia N95, a Nokia 3510, a Motorola v3, a BlackBerry, an iPhone 3.0, a Windows Mobile device, and a Japanese phone from the carrier Au:

  • Mozilla/5.0 (SymbianOS/9.2; U; Series60/3.1 NokiaN95/20.0.015 Profile/MIDP-2.0 Configuration/CLDC-1.1 ) AppleWebKit/413 (KHTML, like Gecko) Safari/413

  • Nokia3510i/1.0 (05.30) Profile/MIDP-1.0 Configuration/CLDC-1.0

  • MOT-V3i/08.B4.34R MIB/2.2.1 Profile/MIDP-2.0 Configuration/CLDC-1.1

  • BlackBerry8100/4.2.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 VendorID/125

  • Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A538a Safari/419.3

  • Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240×320)

  • UP.Browser/3.04-TS14 UP.Link/3.4.4

As you can see, there is no standard for this string. So, the initial approach is to search for some term—for example, “iPhone” or “Symbian”—to try to determine which device or platform a request has originated from. Don’t worry if this sounds nightmarish, though; in a few pages we will talk about a better solution.

iPad or iPhone?

When the iPad (the Apple tablet) came to the market, many thought that servers would automatically redirect iPad users to the iPhone versions of websites, if they existed. That is because the iPad uses iOS, just like the iPhone itself and the iPod Touch.

However, the iPad User-Agent header looks something like this:

Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10
(KHTML, like Gecko) version/4.0.4 Mobile/7B367 Safari/531.21.10

As you can see, it doesn’t contain the word “iPhone,” and that is one of the ways that developers detect usage of iPhone-based devices. It does include the word “Mobile,” though, so if you are looking for that word you will be able to tell that the user is on a mobile device.

That said, because the iPad has a larger screen and can show more content than a mobile device, mobile websites are not ideal. Some big sites have created special iPad versions using mobile Safari extensions; these are neither the mobile nor the desktop web versions, but somewhere in between.

The iPod Touch does include “iPhone” in the user-agent string, because it is so similar (in terms of the operating system and screen size) to the iPhone itself.

1.4. What we can identify

Identification is useful for context definition. We need to remember that the user is a mobile user, and for these users the context is very important. We want to get all the information we can about that context, so we can provide the most useful experience possible.

The mobile browser doesn’t send information about:

  • The International Mobile Equipment Identity (IMEI) or serial number to identify the device uniquely

  • The type of network used (WiFi, 3G, GPRS, EDGE, CDMA)

  • The carrier (operator) providing service to the device

  • The country of the user

  • If the user is roaming

  • The phone number of the user

  • The device’s brand and model number (not directly)

Some of this information (carrier, brand, and model number) can be inferred, but the other identification data will not be available. That is why we cannot identify users automatically without a login, as in desktop web applications.


If you are working closely with the carrier for your mobile website, you may be able to have yourself added to the WAP gateway’s URL whitelist. You will then be able to receive a customer ID or phone number in a new nonstandard header.

Here’s what we can glean from the device headers:

  • The carrier and country, from the IP address of the request (if it is using a 2G or 3G network).

  • The country (and maybe city or even location), from the IP address of the request (if it is using a WiFi network).

  • The brand and model number, inferred from the User-Agent header.

  • The language in which the operating system is defined.

  • What markups and document types are accepted, if the header is not defined as */*.

1.5. The User Agent Profile

The UAProf (User Agent Profile) is a voluntary standard defined by the Open Mobile Alliance (formerly WAP Forum). It takes the form of an XML file defining the abilities of the device, including its screen size, download features, and markup support.

The XML is defined by the manufacturer or the carrier, and a link to the XML is defined in a header (typically x-wap-profile).

x-wap-profile: ""

This URL will have been defined when the browser was created, which may have been several years before. If the URL is still working, we should get XML like the following extract:

<prf:Model>BlackBerry 8100</prf:Model>

UAProf files have many problems. First, we need to download the XML for each request, process it, and either extract the properties we want or make a local copy on our server. Second, the community has found lots of bugs and problems in this official information. Some devices (the iPhone, for example) don’t define a UAProf file, and they don’t define the same properties. Also, UAProf does not have the right granularity of information; for example, you can read that Flash is supported, but no information is there about which version.

So, another problem added to our list.
  •  Using Windows Phone 7 Technologies : Retrieving Accelerometer Data (part 2)
  •  Using Windows Phone 7 Technologies : Retrieving Accelerometer Data (part 1)
  •  Using Windows Phone 7 Technologies : Understanding Orientation and Movement
  •  Programming the Mobile Web : HTML 5 (part 4) - Client Storage
  •  Programming the Mobile Web : HTML 5 (part 3) - Offline Operation
  •  Programming the Mobile Web : HTML 5 (part 2) - The canvas Element
  •  Programming the Mobile Web : HTML 5 (part 1)
  •  Windows Phone 7 : Submitting Your First Windows Phone Application to the Windows Phone Marketplace
  •  Windows Phone 7 : Packaging, Publishing, and Managing Applications
  •  Mobile Application Security : Windows Mobile Security - Development and Security Testing (part 3)
  •  Mobile Application Security : Windows Mobile Security - Development and Security Testing (part 2)
  •  Mobile Application Security : Windows Mobile Security - Development and Security Testing (part 1)
  •  Programming the Mobile Web : Mobile Rich Internet Applications (part 2) - JavaScript Mobile UI Patterns
  •  Programming the Mobile Web : Mobile Rich Internet Applications (part 1) - JavaScript UI Libraries
  •  Windows Mobile Security - Kernel Architecture
  •  Windows Mobile Security - Introduction to the Platform
  •  iPhone Programming : Table-View-Based Applications - Building a Model
  •  Mobile Application Security : The Apple iPhone - Push Notifications, Copy/Paste, and Other IPC
  •  Mobile Application Security : The Apple iPhone - Networking
  •  Windows Phone 7 Development : Handling Device Exceptions
    Top 10
    Maintaining Windows 7 with Backup and Restore (part 1) - Creating a Backup & Restoring Files from a Backup
    SharePoint 2010 :Implementing a Partner Extranet Solution (part 2) - Configuring Authentication Providers
    Ovation: Wireless Headset, MOTOACTV, LIVESTRONG
    Graham Morrison: The advocate
    The choices of mobile computing for SOHO users (part 3)
    Keep up to date with Windows Update
    Complete Guide for Your PC & How to Buy It (Part 3) - Lenovo ThinkPad Edge E520 & Toshiba Portégé Z830-104
    Backing Up the Exchange Server 2010 Environment : Supporting Backups with Documentation
    Understanding Mobility Enhancements in Exchange Server 2010
    Exchange Server 2007 : Configure the Client Access Server - Create and Apply ActiveSync Mailbox Policies
    Most View
    SQL Server 2008 : Managing Query Performance - Running the Standard Performance Reports
    Programming the Mobile Web : WebKit CSS Extensions (part 4) - Animations
    Maintaining Windows 7 with Backup and Restore (part 2) - Using Advanced Backup Options & Using System Protection
    Algorithms for Compiler Design: LEXICAL ANALYZER DESIGN
    Building Android Apps : Controlling the Phone with JavaScript (part 1) - Beep, Vibrate, and Alert
    iPhone Application Development : Using Advanced Interface Objects and Views - User Input and Output
    iPhone Application Development : Getting the User’s Attention - Using Action Sheets
    Getting the Most Out of the Microsoft Outlook Client : Deploying Outlook 2007
    Exchange Server 2010 : Deploying a Database Availability Group (part 3)
    Download Web Content via HTTP
    Windows Server 2008 : Keeping a Distributed Environment in Sync
    Microsoft Content Management Server Development : Managing Channels and Postings with the PAPI - Moving Postings
    Programming with DirectX : World Transformations
    SQL Server 2008 : Transact-SQL Programming - Ranking Functions
    Windows 7: Managing Software Once It’s Installed (part 3) - Viewing and Managing Startup Programs
    Windows 7 : Networking with TCP/IP (part 1) - Understanding IPv4 & Using Private IPv4 Addresses and Networking Protocols
    The .NET Security Architecture
    Identifying the Technical Goals and Objectives to Implement Windows Server 2008 R2
    Worker Processes, Application Pools, and Identities in IIS 7