Tiffany Brown by Tiffany Brown in Blog

Post tags: http odin opera-mini opera-mobile

This post is licensed under a Creative Commons Attribution 3.0 Unported license.

Introducing Device-Stock-UA: A New Request Header and Proposal

Our latest releases of Opera Mobile and Opera Mini will include a new header: Device-Stock-UA. The value of this header matches that of the stock user agent bundled with the operating system on which Opera Mobile or Mini is running. Below is an example of what this header might look like on an Android device (a T-Mobile myTouch4G).

Device-Stock-UA: Mozilla/5.0 (Linux; U; Android 2.3.4; en-us; myTouch4G Build/GRJ22) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
<p>We&#39;ve set a precedent for such a header with <code>X-OperaMini-Phone-UA</code>. Opera Mini includes this header with every request. Other headers, such as <a href="http://mobiforge.com/developing/blog/x-device-user-agent-header-appearing-requests">X-Original-User-Agent and X-Device-User-Agent</a> exist in the wild and function similarly. None of these headers are standard. Nor do they comply with <a href="http://tools.ietf.org/html/rfc6648">RFC 6648</a>.</p>

To that end, we're proposing Device-Stock-UA as an industry standard. A draft version of this RFC is available on GitHub. Please contribute and comment. We've worked closely with dotMobi on this proposal; it is also implemented in their goMobi service.

Why introduce a new header?

<p>The goal of Device-Stock-UA is to help mobile site and application developers determine the device on which an HTTP client is running and adapt content accordingly. In mobile-centric web development, there&#39;s a tension between the &#8220;<a href="http://www.w3.org/TR/mobile-bp/#OneWeb">One Web</a>&#8221; philosophy and the realities of networks, protocols, device hardware, and user agent capabilities. We think that this header will lead to a better experience for Opera Mobile and Opera Mini users. And we think this can be useful for other user agents as well.</p>

By embracing the “One Web” philosophy, developers can choose to build a single, responsive experience for a range of devices. Feature-detection and progressive enhancement ensure that any capable browser — not a single, dominant browser — has access to a given resource. Innovations such as meta viewport / @viewport and media queries allow us to streamline development and maintenance with a single code base. It's the approach we advocate here at Opera.

But from a pragmatic point-of-view: data plans cost money and time. Serving fewer bytes helps companies contain bandwidth costs. While we're looking forward to how responsive images will solve a number of these problems through declarative markup, we see a lot of developers choosing server-driven content negotiation: serving markup, CSS, JavaScript, and images based on the value of the User-Agent header.

Most widely-used APIs for server-driven content negotiation use the User-Agent header to infer browser and device capabilities. They assume a one-to-one relationship between a User-Agent string and a device. Opera Mobile and Mini use platform-specific user agent strings — as with desktop browsers — that do not include device information. For Opera Mobile in particular, this created site compatibility and content optimization issues. With no way to determine the device, Opera Mobile would be served the same small images and basic markup as feature phones. The X-OperaMini-Phone-UA header prevented Opera Mini from facing similar issues.

Phasing out X-OperaMini-Phone-UA

In the short-term, Opera Mini will send both the Device-Stock-UA and X-OperaMini-Phone-UA headers. Opera does not have a definitive cut-off date for removing the X-OperaMini-Phone-UA header, but it will happen eventually. We'll also work with popular mobile content negotiation APIs to add support for Device-Stock-UA.