Nicholas Hagen

One of the features of HTTP that is widely used, yet strangely a hack, is the User-Agent header. Several sites and servers use the agent to detect a browser’s capabilities. For example, a site may attempt to detect IE browsers to handle custom stylesheets or javascript. A more traditional approach as of late is detecting mobile browsers to handle content and layout properly. However, in any of these cases, this is really just a kludge IMO. The user agent header was more or less just a descriptive way of telling a server what it was. With the future of the web moving along with the likes of HTML5, CSS3, JS.next, etc, I think it is about time we update the HTTP protocol as well.

I propose we add one or more feature headers that list the supported features of a device. CSS3 somewhat has this with media queries, but it only applies to CSS. Javascript, via the DOM, has the ability to query features as well to some degree. There really is no way to do it across the board consistently and no way to detect from the server side or even through a router or proxy.

I would think at a minimal some the following are supported:

User-Agent-Features: html(5), javascript(1.8), css(2.+,3), video, audio

This would basically be a comma separated list of features with known values defined by the spec. Versions could also be supported to denote what level of support exists. The Telnet protocol has something like this to tell the terminal what features are supported. The defined features should be high level to avoid creating too long of a header string increasing bandwidth.

X-User-Agent-Features: feature1, feature2, feature3

This would follow suit with the above features but would allow the browser to expose non-standard features. This may make sense to just combine rather than having a separate header. I kept separate only to ensure at least a predefined set of consistent features existed to avoid one vendor using one name and another vendor a different name.

The beauty of this approach is that you can easily use regex to determine support at the client or server level. Further the client could use a DOM API to query the feature sets:

var supported = document.isFeatureSupported('video');
if (supported) {
    // inject video player
}
 
var features = document.getSupportedFeatures();

Further, a router could be utilized to analzye the header for a given feature and route it differently (ie: video vs no video). Since the features are pre-defined and known values, this becomes incredibly easy.

User-Agent-Media: mobile | tablet | laptop | desktop

This would denote the type of device similar to a media query in CSS3. The list of supported media should include a predefined list of known media types. This way the server can easily route without dealing with constantly changing user agents where a new definition arises everyday from a new device it seems. The big issue here is where some devices border those relationships and act as multiple instances. For example, a tablet could be a mobile device as well and even a laptop to degree. A comma separated list may work better in these situations. Another idea would be modeling after the language header where each language has a metric of priority. This way a vendor can say the device primarily supports tablets, but also laptops as a fall back.

User-Agent-Orientations: portrait(320x460), landscape(460x320)

This tells what orientations are supported and the max allowed size for that orientation. Typically this would just be a single value but for mobile devices they can list both with the first listing as the active orientation. Devices with an orientation switch could remove the landscape option when that switch is enabled.

These features would all help to better handke the growing list of devices, browser vendors, and all the differences between them without resorting to hacks.

Filed under:
Standards, Web Design by Nicholas Hagen