Seriously, has this ever actually happened?! Nobody would store version number in a 1 digit char field. They’re more likely to store it as a string or an int..

1. Brent Tilley

   My immediate thought to this article’s title was that people have used a function similar to that of PHP’s strpos() and checking for a “1” after extracting the version number. This of course would return true for a browser with a version of 10, 11, 12, etc.

   January 31st, 2012 at 13:48

2. Yehuda

   @Nick
   Storing the version number as a string could lead to a problem in version detection. In JS, if you test “10.0” >= “3.6”, you’ll get the Boolean false, because this is a string comparison, not a numerical comparison.

   January 31st, 2012 at 14:53

3. Simon

   It’s not a matter of storing it in a 1-digit field – it’s a matter of what they’re looking for. Our web-based app blacklists older browsers that we know don’t work, and it did so by looking for the string “Firefox/1” in the user agent. And that, of course, matches “Firefox/10”, causing the new version to be blocked.

   Easily fixed, of course – I’ve changed it to specifically look for a dot after the one, which still matches the older user-agents, but not FF10. But it *did* need fixing.

   January 31st, 2012 at 15:19
   1. Nick Gilbert

      OK I see the problem. Personally though, I would never write code which treats numbers like a string as it’s a stupid idea for obvious reasons and I be tempted to sack anyone who put those kinds of hacks near my code… :)

      January 31st, 2012 at 15:48

   2. Nick Gilbert

      …especially as it’s so obvious that that code can’t work. It’s about as stupid as checking to see if the browser is firefox by seeing if the string “Fire” is anywhere in the user agent string. It might work for a bit, but when a browser called Fireblaze comes out, you’re screwed.

      January 31st, 2012 at 15:52
      1. Brent Tilley

         Not to mention the user agent string can be spoofed to be just about anything.

         January 31st, 2012 at 16:03

      2. Simon

         Eh, it worked for what it was intended for, which was to detect people running an unsupported browser, and redirect them to a page telling them so.

         It’s an enterprise app, so supporting every browser under the sun isn’t an objective – it just needs to recognize Firefox and IE, and distinguish between supported vs unsupported versions of both. And if they work around it by spoofing the user agent, no big deal – it just means there’s no point in them reporting problems, because “which part of ‘unsupported’ did you not understand?”.

         January 31st, 2012 at 19:11
         1. ZiggyTheHamster

            Enterprise app or not, excluding “unsupported” browsers because they’re not Firefox or IE is not a good practice. Iceweasel is Firefox-compatible, but can’t access your app because it’s not supported.

            February 13th, 2012 at 14:35

I tend to avoid UA sniffing when possible, but one frequent use I have is checking for the presence of CSS3 gradient support server-side. I wrote a PHP function that checks if a user’s browser appears capable of rendering CSS3 gradients; and if not, it outputs a stylesheet link that loads background-images into the DOM.

Now, I could have always included the background-images *before* the lines that declare the linear or radial gradients, but I noticed WebKit still sends out a HTTP request to the URI (whereas Firefox doesn’t). In the interests of optimising server demand as much as possible, I decided to only have those background-images loaded for browsers that appeared in capable of rendering gradients.

So far, it’s worked a treat. Worst that could happen is a solid colour showing up in the background anyway. But this is one example of how UA sniffing can be used for something fairly minor and cosmetic.

Ironically, the ‘Articles by Category’ on the right-side of this web page lists “Firefox 10” before “Firefox 3.5”.

1. Chris Heilmann

   hah! the perils of sort vs natsort :) well spotted.

   February 15th, 2012 at 04:07