Comments on: Skyfire Launch – Proper Mobile Browser Behavior http://www.thisismobility.com/blog/2008/01/28/skyfire-launch-proper-mobile-browser-behavior/ Ripping mobility from the clutches of telecom Thu, 29 Dec 2011 20:46:11 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Johan Schön http://www.thisismobility.com/blog/2008/01/28/skyfire-launch-proper-mobile-browser-behavior/comment-page-1/#comment-237995 Johan Schön Mon, 11 Feb 2008 00:32:18 +0000 http://www.thisismobility.com/blog/2008/01/28/skyfire-launch-proper-mobile-browser-behavior/#comment-237995 Steve, the problem we saw with including the device identifier in the UA was that some sites would give us WAP 1.0 content e.g. when they spotted the word "Nokia". Steve, the problem we saw with including the device identifier in the UA was that some sites would give us WAP 1.0 content e.g. when they spotted the word “Nokia”.

]]> By: Steve Metcalfe http://www.thisismobility.com/blog/2008/01/28/skyfire-launch-proper-mobile-browser-behavior/comment-page-1/#comment-232812 Steve Metcalfe Tue, 29 Jan 2008 10:48:25 +0000 http://www.thisismobility.com/blog/2008/01/28/skyfire-launch-proper-mobile-browser-behavior/#comment-232812 I think the issue here is the need to identify not only the browser, but also the device. UAProf's have this ability, (especially with the diff header), but haven't seen very good adoption. Most user agents in the web world already indicate both the browser and the OS. What is to stop the User-Agent being an extended form of something like: Mozilla/5.0 (SonyEricssonK800i/R1JC) This, along with suitable accept headers indicating supported content types that would be passed through directly to the native browser (Like OMA mime types) would be a clean solution? It identifies the browser to allow the site to select an appropriate rendering, but also indicates the device keeping people needing to target content at specific handsets happy. Some of the earlier Opera Mini releases I saw presented the underlying device as part of the user-agent, but this seemed to be phased out later on, which is a pity in my opinion. The disadvantage of using headers other than the user-agent and other common ones (accept header for example) to tailor the presentation, is that most proxies are very flaky with properly handling the vary header for caching except when used with common headers. Steve I think the issue here is the need to identify not only the browser, but also the device. UAProf’s have this ability, (especially with the diff header), but haven’t seen very good adoption.

Most user agents in the web world already indicate both the browser and the OS.

What is to stop the User-Agent being an extended form of something like:

Mozilla/5.0 (SonyEricssonK800i/R1JC)

This, along with suitable accept headers indicating supported content types that would be passed through directly to the native browser (Like OMA mime types) would be a clean solution? It identifies the browser to allow the site to select an appropriate rendering, but also indicates the device keeping people needing to target content at specific handsets happy.

Some of the earlier Opera Mini releases I saw presented the underlying device as part of the user-agent, but this seemed to be phased out later on, which is a pity in my opinion.

The disadvantage of using headers other than the user-agent and other common ones (accept header for example) to tailor the presentation, is that most proxies are very flaky with properly handling the vary header for caching except when used with common headers.

Steve

]]>