It is very common that over the years something gets more and more cluttered, until at some point someone comes in and decides it’s time to clean up and start fresh, based on current and up-to-date needs. User-Agent strings, part of the HTTP request headers, are no different and between desktop and mobile browsers, the history is long and the amount of text (some might say useless text) has just kept growing. I am going to try and write down what is important today and why.
A little introduction is probably needed. I have been the maintainer of WURFL, a device database, for about 5 years and then worked on another device database called DeviceAtlas for another 3 years. During these years I also worked with the W3C and in general with the mobile Web community to define how the mobile Web should look like and what developers needed to do their job better.
I am going to take four User-Agent strings for four platforms that are meaningful for mobile and analyse what is useful today, what they have currently and what they should have. I will also briefly jump into some other headers as they can help in a number of situations.
User-Agent string definition
A clarification here is probably needed. Let’s start from what the User-Agent string is, if you don’t know. When an HTTP client such as a Web browser makes a request to a server it sends a number of headers as part of that request. One of these headers is called User-Agent and it is meant to identify the client. This is how it is defined in the RFC-2616:
The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. The field can contain multiple product tokens (section 3.8) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokensare listed in order of their significance for identifying the application.
User-Agent strings in mobile
In the mobile space specifically this string has historically been used to recognise devices. Since each device has very specific features and installing third party plug-ins has always been (and still is) nearly impossible, recognising a device easily is fundamental to the creation and provision of content that is not only optimised for a device, but often that it is simply supported. In the early 2000 the User-Agent string of a Nokia 7110 was “Nokia7110/1.0 (04.84)“. At that time it gave all the information that was needed. Over the years a lot of information has been added and eventually, recently, a lot of mobile browsers have started emulating the strings that were usually provided by desktop browsers, unfortunately picking up a lot of useless information and removing what was useful.
The analysis
Here are my four sample User-Agent strings, an iOS 4.1, an HTC/Google Nexus One, a Nokia N8 and the latest Fennec on an Android device:
- Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-gb) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7
- Mozilla/5.0 (Linux; U; Android 2.2; en-gb; Nexus One Build/FRF83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
- Mozilla/5.0 (Symbian/3; Series60/5.2 NokiaN8-00/010.016; Profile/MIDP-2.1 Configuration/CLDC-1.1 ) AppleWebKit/525 (KHTML, like Gecko) Version/3.0 BrowserNG/7.2.5.2 3gpp-gba
- Mozilla/5.0 (Android; Linux armv7l; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre Fennec/4.0b1
iPhone User-Agent string
Let me start with the first one, the iPhone. There are a number of things here of interest: that it’s an iPhone, the software version, the type of browser and possibly the browser version. I will get back to why the browser version may or may not be useful later. Do we care it’s “like Mac OS X“? Do we care that “KHTML (is), like Gecko“?
So what we could do is strip out everything that we don’t need and
Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-gb) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7
becomes
iPhone/4.1 AppleWebKit/532.9
If I was a VP at Apple and had any decision power I would also specify the iPhone model and it’s probably a good idea to also be explicit about the vendor (it happened that two vendors named two devices the same way). Here is a very short string that tells me everything I need:
AppleiPhone4/4.1 AppleWebKit/532.9
Google Nexus One User-Agent string
Second on my list is the Nexus One, again a lot of information we don’t need. Who needs to know it’s Linux when we can’t really hack the kernel or install X.org (at least from the browser!)? Who cares about the language when there is an appropriate header for that called Accept-Language? So what we have is
Mozilla/5.0 (Linux; U; Android 2.2; en-gb; Nexus One Build/FRF83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
but what we should have is
GoogleNexusOne/2.2 AppleWebKit/533.1
Nokia N8
Nokia, with the N8 and a lot of other devices has taken the best of all worlds. On one side emulating a desktop browser and on the other side bringing all the extra information about J2ME, audio and video streaming and other details that have been meaningful in the mobile space at some point in time. The sad truth is that all these supported environments and protocols are so fragmented that the name alone is not useful and hence, just a burden. Let’s clean up the house, remove the information that the device supports MIDP-2.1, because anyone who has ever seen the build-chain of a J2ME application knows that you need to know a lot more about the specific JSRs that are available and of course the device-specific quirks. Also, don’t forget that this is just an example, Sony Ericsson, Samsung, LG and the other vendors are all more or less the same. So bring some fresh air, leave space for what is important and change this
Mozilla/5.0 (Symbian/3; Series60/5.2 NokiaN8-00/010.016; Profile/MIDP-2.1 Configuration/CLDC-1.1 ) AppleWebKit/525 (KHTML, like Gecko) Version/3.0 BrowserNG/7.2.5.2 3gpp-gba
to this
NokiaN8/010.016 BNG/7.2.5.2
In this case specifically, we probably need one little extra information. All the Symbian devices by Nokia in the last few years also have an environment called Web Runtime or WRT that lets you create Web applications that look like native applications, are installed on the device and can access device APIs. So we could use “B” or “BNG” for the browser and “W” or “WRT” for the Web Runtime, so if you developed a Web application and request a remote page, the server will know if it can send extra Javascript to pull up the device location or contacts and so on. It’s a nice piece of information to know, right?
Fennec on Android
Now on with my last example and I am picking Fennec on Android simply because it’s probably the newest kid on the block, but the exact same comment would be valid for Opera browser and other third party browsers that you can install on your mobile device. For starter, there is no reference to the device, there are a already more than 100 of Android devices, how will I know which one? How will I know if it’s Android 2.2 with Flash or not? So this is what we have today
Mozilla/5.0 (Android; Linux armv7l; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre Fennec/4.0b1
This is what we should have (and for the sake of this example I am assuming the device is a Nexus One):
HTCNexusOne/2.2 Fennec/4.0b1
Now, you might comment that I will know if Flash is available looking at some other headers. Well this would be true, if the browser sent the appropriate information. If you have been into mobile detection for a little while you will know that since day one you could not trust the Accept header, mostly because browser vendors have been very bullish about their ability to support content, to then generally disappoint their users (and most of all the _customers_ of mobile sites and content providers). For example the Accept header of this Fennec for Android is “text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8” (see the full headers recorded on logme.mobi). As you can see, this browser supports ANYTHING (the little */* towards the end), isn’t that great? Now, will it play a real-video? Probably not. Will it play Flash? MAYBE! Will it play an H.264 video? I don’t know. Oh, yes, these are the same Accept headers that Firefox for PC sends, but it is also true that on my PC or Mac I can download the file and play it with VLC or I might want to download a Word document and read it later. On mobile devices it’s slightly different and most mobile devices do not let you download and store files and even after I have downloaded it, my context is normally such that if I cannot read the file now I don’t care. Hence the server needs more information in order to provide the right content; the server might have the file in the right format, if it knew what is supported.
PS: In fairness Opera Mini adds extra headers to tell you the device it is running on, when they know it and this depends on how you installed the client.
Conclusions
I am not advocating overloading the headers, we have examples of other headers sent to the servers that are nearly completely useless. Looking at the N8 again, it sends a header about the Music shop version (X-Nokia-Musicshop-Version: 13.1012.15), do I care? Unlikely. Would I care to know the version of Ovi Maps installed so that I can provide a link that will launch the Maps application? More likely!
As you might have noticed, I have stripped the “Mozilla/” at the start. There is a myth that servers will not provide the Web site or will provide a very limited version of the site if that string is not there. I have asked many times and although everyone seems scared of this, I do not know of a single site that really does it today. If you know one, please let me know and most of all WHY is this site doing this?
One final note, earlier I said that the browser version might not be required. As a rule of thumb I would say that if the server knows the browser version it’s better because the server will either not care, or if the site actually has different versions for different browsers it can provide that version. In the future I hope that what will matter is just the browser, i.e. is this a standards-compliant browser? If so, I can use Javascript to detect what works and what doesn’t or I can create my CSS in a way that degrades gracefully. Today, I think we are on the right track and things are quickly moving in the right direction, but we are not there yet, so for the next 1 or 2 years and until everyone gets a new shiny devices with a cool browser, we will have to be a little patient on this and try working together on what is still not solid enough.
So please, if you are browser vendor, take out what is not useful and keep what developers need.
Andrea Trasatti's tech notes and more 
Hi, I’m on the Fennec development team.
Note that the iPhone useragent does not tell you whether the user has an iPhone 2G, 3G, 3Gs, or 4. For web developers, the main difference between models is the new display on the iPhone 4. Instead of using the UA sniffing to detect this, you can and should use things like CSS media queries. (Some media queries are broken in Fennec’s beta builds; we’re working on it.)
Is the difference between Android models more important than the difference between iPhone models? Can you give some examples of why you would need to serve different content to a Nexus One than to a Droid? Then we can make sure that your use cases are supported. If the best way to do it is to add more info to the useragent string, then that is an option for us. However, note that each bit of information added to the UA is a privacy risk because it makes fingerprinting attacks more effective.
The UA has never been a reliable way to detect Flash support. In fact, your suggestion that Fennec on Android 2.2 would support Flash is wrong – current Fennec versions do not support Flash on any Android version. Future versions might support Flash on versions other than 2.2. Fortunately, techniques for Flash detection and fallback are well-established; Adobe even provides code you can use.
If your page includes an img, video, or audio tag, then the request Fennec sends for the image/video/audio resource will include more specific MIME types in the Accept header. This is nothing new; it’s exactly what Firefox for PC has done for years. (Also, Firefox for Android does let you save files for later and open them in other apps.)
In summary, if the Flash objects and media files on your page have detection and fallback that work in Firefox on the desktop, then they will work in Firefox for mobile. We would like to provide the APIs web developers need to deal with device differences. CSS media queries and HTML5 and related standards provide some of these tools. If there are important use cases that are missing, we’d like to hear about those use cases. We prefer to provide these via web standards. UA sniffing has never been a good way to build reliable, forward-compatible, cross-browser web sites.
LikeLike
I should mention that we are making an effort to remove irrelevant information from the user agent, and add or retain relevant information. See Final User Agent String for Firefox 4 for details. (Our mobile user agent strings are less tested at this point, and we can still change them if needed.)
Many of your suggestions (like removing “Mozilla/”) are things that we very much want to do. Unfortunately when we’ve them, we have discovered that many sites do have fragile regexps that rely on the current structure of the user agent string. It’s beyond our power to convince all of these sites to change at once, so we’ve decided that we can’t make these larger changes without seriously inconveniencing a lot of our users (and causing them to switch to a browser that still has the old-style UA).
You can look in our newsgroups for discussions of some of the changes that were considered and rejected, for example in this thread.
WURFL is a great tool, and Mozilla’s web team uses it on some of our sites. (Thanks!) But we’ve also learned that many users use hacks or preferences to spoof the useragents of other devices. Any advice on how to deal with that?
LikeLike
Right on. I’d argue that the technology for this here today, even if the public libraries are not.
We use an approach like has.js, modrnizr and master-class for client side feature detection. An initial capability detection page “capability cookie” on the browser.
The capability cookie is read by the webserver to decide what form of content to serve!
LikeLike
iPhone/4.1 AppleWebKit/532.9 => So the AppleWebKit version supercedes the nominal Mobile Safari version? Also, I assume you were advocating they put the actual model number: i.e. iPhone3G, iPhone3Gs, iPhone4, etc, otherwise you haven’t solved the main problem afflicting Apple detections.
=> accept strings -> correct that the appearance of */* and text/html mean very little, but it’s a big long step to say they should all be ignored.
HTCNexusOne/2.2 Fennec/4.0b1 => hugely bad idea to remove the Android reference, IMO. RandomChinesePhone/2.2 is much less useful than RandomChinesePhone Android/2.2.
MIDP => it’s actually useful as a very (very) rough guide: this is another example of the assumption that because it’s not perfect it’s not usable
Missing out OS and DP out of the Nokia string? That seems like a REALLY bad idea.
Nexus One string: I’m still on the fence about whether the proper version number is the 532 one, or the Version/4.0 one. WURFL and others use the version 4.0 in preference to the 532 which currently DetectRight uses. And the Android designation version has disappeared again.
Anyway, this is all academic since nothing will change about this, and the focus on device fragmentation will move slightly away from markup issues (though not much, since full websites are still a bad idea on even very capable mobile devices) and onto media. And the number of devices and useragents in the wild is increasing much faster than traditional device detection systems can keep up with, especially from smaller manufacturers in emerging markets.
The main challenge in device detection here is not parsing useragent strings but keeping up with the raw devices outside the cosy little Western European big-manufacturer ecosystem.
LikeLike
Hi Matt,
my point on the iPhone not showing the version was exactly the opposite of yours, i.e. not seeing it is a problem. On the server side I might decide to go conservative on the use of bandwidth knowing that you have a device that might be on EDGE.
The iPhone4 allows you to detect the higher pixel density with a media query and that’s very nice, but Apple is also very good at keeping their product consistent. On the Android side you have currently set a requirement of Android 2.0 and I assume many devices have the same specifications, but does that hold true for the future, even the next 6 months? How am I going to know the user is on a Nexus One and not on a Samsung Galaxy Tab?
Similarly, my point about downloading is exactly the opposite as yours, i.e. on the mobile I like want to see the content immediately or not need it. The different context requires different options, it is NOT a PC, even if it ran on an Intel Core Duo.
I don’t understand your point about fingerprinting. How is knowing that you have a Droid, a Nexus One or a Galaxy Tab going to help me identify you? Isn’t a cookie much easier to use?
Flash, I was concerned it might be a bad example and we would get stuck in that small field. My point is not about detecting Flash in itself, it was a way to explain that even if a device runs a certain OS, it does not mean all devices are the same. This applies to other media types. Your example about images and video makes me wonder what is your recommendation those media files, I gather that you suggest to create for example an object tag, embed a video specifying a URL and then when the browser requests the server reads the MIME type and provides the right file. That might work, but requires that all my media files are actually a dynamic URL, if I create my object tag with a static file and the encoding is wrong it will not work. Am I supposed to create the object with all possible fallback combinations of all the media formats I have created? Specifically in video, this is going to be a lot of HTML.
Finally, on removing “Mozilla”, I don’t get your point. On one side you tell me that no, you will not help servers to recognise your device because that’s not the right thing to do, but you keep supporting sites that you say use “fragile regexps”.
Also, you are falling in my list of people mentioning the myth of Web sites breaking and not providing a single example. Oh, and FYI I had seen a bug report for Firefox 4 breaking on Hulu because Hulu does not recognise it properly. That is exactly the type of high-end site that should be preached to use best practices and still doesn’t. To be honest, if Geocities-like sites (God bless Geocities!) created in the 90s don’t work properly on a mobile it’s not a tragedy.
And one more thing, check out this great presentation by Yiibu showing how media queries can be a very lazy solution that creates more costs and longer wait for the user if not used properly. Rethinking the Mobile Web by Yiibu.
PS: And everyone looking at this blog can see how Yiibu have created a great site with “mobile first” in mind that is fast and uses media queries the right way.
LikeLike
Chris,
you are probably right, for the iPhone we should talk about the mobile Safari version. Maybe my copy and paste was hasty, but the example of Fennec and Nokia better represent what you are saying.
On Android, Nokia series, etc I am more or less in agreement with you. I had an earlier version of the post where for example the suggested User-Agent string for the N8 was NokiaN8/010.016 S/3 BNG/7.2.5.2 where “S/3” means Symbian 3 and for previous devices it would have been something like “S60/3.2” or “S60/5” and so on. This would also play very well for the Nokia S40 with WebKit for example where you would be able to match the fact that’s not a Symbian phone, but runs a good browser.
On the MIDP, unfortunately you have not convinced me. I don’t see how many J2ME applications you could deliver with that sole information, but I might be wrong.
As a note, this post was about starting fresh and adding what we need today. All the suggested User-Agent strings are as short as possible and I might have cut out a little too much.
On your last comment you are right, even though we complain and scream about what we have here, what we have from the large manufacturer and browser vendors is much better than what the Chinese and Indian manufacturers are offering for the low-price market. I am hoping that with the leadership of Western OSs and browsers same rules can be applied elsewhere.
LikeLike
Chris,
I forgot to mention that Series are very useful for Nokia, but not equally useful for other vendors. It would be great, of course, to be able to identify device families for all.
Possibly, at least for browsing, a device grouping that was cross-vendor. We need someone to main this, of course 😉
LikeLike
Andrea,
Oops, you are right that you had the same advice about device models for both Safari and Fennec. Somehow I missed that in the iPhone section of your article before. Sorry!
Fingerprinting is a technique that takes advantage of UA string differences (and other differences between users’ browsers) to circumvent controls on cookies. If your browser sends enough unique information to the server, then it can track you even in cases where cookies should be disabled. For details, see this EFF site.
“On one side you tell me that no, you will not help servers to recognise your device because that’s not the right thing to do, but you keep supporting sites that you say use ‘fragile regexps’.”
I hope you can see that from our point of view there’s a big difference here. Remaining compatible with existing sites is important for our users, especially when we can do it at little cost to users and developers. We don’t have very good control over existing sites. But we do have control over our own code, and we can try to use that to influence new sites, and avoid creating more similar problems in the future.
Sorry, I wasn’t directly involved in the testing of the various UA changes and I don’t know any example sites off-hand. The best info I could find just now is https://bugzilla.mozilla.org/show_bug.cgi?id=527886#c25
“That might work, but requires that all my media files are actually a dynamic URL, if I create my object tag with a static file and the encoding is wrong it will not work.”
Web servers like Apache can be configured to do content negotiation automatically, and select from multiple static files based on the request headers. Or your can provide multiple source URIs in your object/video/audio tag…
“Am I supposed to create the object with all possible fallback combinations of all the media formats I have created? Specifically in video, this is going to be a lot of HTML.”
If you just provide Flash, Theora, and H.264 (or hopefully in the future just WebM and H.264) then you should reach all video-capable browsers. http://diveintohtml5.org/video.html has example code to do this. I don’t think 700 bytes of markup is anything to be concerned about, especially since the user is about to download several million bytes of video.
“How am I going to know the user is on a Nexus One and not on a Samsung Galaxy Tab?”
This is a valid concern, and it’s why I think we might want to include more info in the useragent string despite the disadvantages. You’re right that server-side sniffing has real advantages too. There are trade-offs to be made here, and I really appreciate you talking to us about it so we can change our decisions if necessary.
LikeLike
First, good post Andrea, I like the idea of cleaning up the UA. It would be great to be able to start from scratch and do things right from the beginning.
I understand Matt and Fennec, it’s a hard decision to remove Mozilla from the UA when they know there are sites that depend on it. But why could we not keep the UA as it is and add more header fields with device capabilities instead?
Opera and some Windows Mobile devices does this already, and I find it quite usefull:
http://dev.opera.com/articles/view/opera-mini-request-headers/
Example:
Opera header field:
X-OperaMini-Features: advanced, camera, folding, secure
Winmo header field:
ua-pixels: 240×320
Fennec could do the same thing. Add the original UA and other relevant info that might be useful in additional headers, that will only add information to developers and will not break compatibility with existing sites.
LikeLike
First, as a complement to Andrea’s post, an ironic, but enlightening, historical description of the evolution of user agent ids:
History of the browser user-agent string
Then, about
In the past decade, several manufacturers (of terminals, browsers, proxies) introduced extra HTTP header fields conveying additional information to application servers. All exist outside the RFC norms, are structured according to different conventions, do not provide harmonized values, are redundant with UAProf, and taking them into account requires even more work on the server side.
If one wants to communicate device capabilities to servers, the best way is to rely upon the one existing standard: UAProf. If one ever needs it, a dynamic UAProf mechanism to inform servers about changes in device capabilities from one request to another is integral part of the standard.
If anybody thinks there is really a requirement for additional HTTP fields that go beyond strict device capabilities, then the proper way is to submit a draft to the IETF; do not burden application developers with yet another proprietary suite of X-* fields. Please.
Finally, I must emphatically disagree with the statement
User agent sniffing has in fact been the most practicable, if not the only practicable, way to build cross-browser mobile sites thus far, especially taking into account the facts that techniques such as Javascript, viewport meta-tags or CSS media queries were unavailable until fairly recently and remain so on most so-called feature phones, are still inconsistently implemented in some high-end devices, and that exclusive reliance upon them may lead to nasty performance snags (e.g. CSS media query for mobile is fools gold). This is not going to change much in the foreseeable future, so that a combination of server-side and client-side detection remains the best practice.
This being said, I agree with the gist of the post and the comments: superfluous strings should be purged from the user agent ids, but whether to keep only device+firmware version, operating system+version, browser+version or add specific platform information (Java among others) requires careful consideration.
E.Casais
LikeLike
Great post Andrea. I really like the idea of cleaning up the UA.
My take on this is that it is very important that the UA identifies the device in some way. How else would I know how to optimize my content for this particular device?
I’m glad you’re discussing delivery of video to mobile devices since that’s something I’ve been working on for a couple of years now. Matt asked for an example of why I would want to serve different content to different Android devices. To illustrate why, I think video is an excellent choice.
Let’s say we want to deliver video to two devices, the HTC Wildfire and the HTC Desire. Both are Android devices but their hardware specifications are quite different. The Desire is capable of showing videos with higher quality than the Wildfire (higher bitrate, resolution, framerate). A video clip encoded for the Wildfire would not look that great on the Desire. If I’m using Fennec on these devices the information I get in the request is that it’s an Android device, nothing more. What I really need to know is things like the screen resolution (240x 320 for the Wildfire and 480×800 for the Desire), video capabilities of the device (i.e. level of h.264) and perhaps version of Android. If there’s no information in the UA about what device I will be serving video to, how will I know which video to select? I can’t even look it up in WURFL or DeviceAtlas since the UA isn’t unique for the device.
What about HTML5 and the video tag? Well, even W3C admits that HTML5 is not ready for production (http://www.infoworld.com/d/developer-world/w3c-hold-html5-in-websites-041?page=0,0). Also, in the article mentioned by Matt there’s a lot of info on the issues with the tag today (not working properly in Android & iOS). What I need is a solution that lets me deliver videos based on things like the screen resolution and aspect ratio of the screen, codec support and the decoding capabilities (h.264 and level info) and delivery method (RTSP, progressive download, HTTP live streaming, RTMP, Silverlight smooth streaming etc.). The bottom line is that I must use “user agent sniffing” to deliver a mobile video solution today.
Regarding UAProf I think it’s an excellent solution. Unfortunately, from what I can tell, a lot of the new phones on the market doesn’t have a UAProf (iOS, Windows Phone 7 and the majority of Android devices).
LikeLike
Hello,
It is IMHO very important indeed to keep “Android” anywhere in the UA string along with the OS version.
Anyway this all UA string thing just need an international norm.
LikeLike
It’s great if a browser puts all the relevant data in a user agent string without adding useless extras.
It would be even better if browsers had the additional option of letting the user decide what’s in the string and what’s not.
You may have mobile version of your site that you send to any browser that identifies itself as running on a phone, but what if I want to view the full desktop version of your site on my Nokia, if I don’t want to tell you that I have Ovi Maps installed, not tell you that my browser supports media format x because I prefer format y instead? And if I want to see your movie at the highest quality settings instead of a watered down low resolution version my mobile browser should identify itself as a desktop browser.
The problem with most mobile web browsers is that the user agent string is hard-coded into the program, which violates the First Commandment of Software Programming: “Thou shalt not hard-code any setting that thy paying customer might wish to customise!”
To cut a long story short: it’s great if a browser puts all the relevant info in a user agent string, but it’s even better if the user of the browser can decide for him/herself what info the browser gives away. Not only for mobile browsers, but for all web browsers.
LikeLike
About the 3gpp-gba on N8 :
According to 3GPP TS 24.109
The UE shall indicate to an application server (i.e. a NAF) that it supports 3GPP-bootstrapping based HTTP Digest authentication by including a “product” token to the “User-Agent” header (cf. RFC 2616 [14]) that is a static string “3gpp-gba” if the HTTP client application resides in the ME, or “3gpp-gba-uicc” if the HTTP client application resides in the UICC, which identifies the feature, i.e. support of GBA-based authentication.
So, this can’t be removed.
LikeLike
I really hope Fennec will include the device info into the UserAgent otherwise lots of mobile site which deliver content will not work anymore. It’s not about web rendering. It’s about delivering customized content to the phones. Especially video and DRM is a huge issue.
Some Androids like the Motorola Milestone do not support DRM with video files while others like the HTC Legend do. Some support wap push, some not. Also animated gifs are not supported by most Androids prior OS version 2.2. The 2.2 Androids can view animated gifs in the browser but you can not view animated gifs in the gallery browser. You want to deliver wallpapers for mobile phones? What is the correct wallpaper size if you don’t know on which handset Fennec is running on?
Some Nokia need 240×320 wallpapers, Androids need 480×320, 640×480 or 960×800, etc.
Some devices support RTSP streaming while others don’t. Which Codec is supported by the device? H.263. MPEG4. H.264, Theora, WebM?
Which H2.64 profile? Baseline, main, high? Which profile levels? How much data can the device store?
Reading out the UAProf also does not help. The info there is incomplete, wrong or missing, the urls to the UAProf file have been changed, do not exist anymore. E.g.: Try to access an UAProf from a Siemens handset…
Without deviceinfo the Fennec browser might be a nice browser to view websites fast and reliable but if you want to access the right content it will be mostly useless.
LikeLike
It’s nice to know which device is talking to your server, but the decision of what content to deliver should not be based on the device type alone.
Just because my phone is capable of using file format X doesn’t necessarily mean I want to receive your file in format X. I might want it in format Y anyway, because I prefer my third party media player instead of the default player. Or because I plan to copy the file to another device later on. Or because I object to the type of DRM used by format X. Etcetera.
Device type is a nice extra, but what a browser should really tell the server is what type of content the user wants to receive, which may be quite different from the default settings of the device.
LikeLike
I think Symbian Underground sums things up perfectly… “Device type is a nice extra, but what a browser should really tell the server is what type of content the user wants to receive, which may be quite different from the default settings of the device.”
Absolutely. The browser should send more context about who is using the device, what the device is capable of, and exactly where it is.
Every time I see one of these debates (great post) I’m reminded of the core problem – devcap – or real time device capability. The more you have the better off your response will be.
LikeLike
Hi Andrea,
My name is Renee and I am a web programmer for a company called american legend.
I got to know your blog through one of the web forum you had discussion long time ago. Here is the link of the webforum. — http://tech.dir.groups.yahoo.com/group/wmlprogramming/message/23448
Yes, I am trying to get idea how to xquery wurfl file in classic asp. the link you have provded– http://wurfl.cvs.sourceforge.net/wurfl/tools/asp/ actually worked couple weeks ago and it did help me a lot. But the link does not work anymore when I tried today. I am just wondering if I can still gain the access to these asp pages?
I know you probably are very busy. I really appreciate your time of reading this letter.
Thank you ,
Renee Wang
LikeLike
Renee,
The best thing to do is check on the wmlprogramming mailing list, someone there might still have something.
Good luck
LikeLike