Bug 7342 – User Agent string not conforming to standards.

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKit Misc.

[Benjamin Derry]

The current user agent from Safari is this:

Browser: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/417.9 (KHTML, like Gecko) Safari/417.8

It needs to be this:

Browser: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/417.9 (KHTML, like Gecko) Safari/2.0.3

Like everyone else. It makes it harder to support the browser on applications that restrict what browsers they support.

Thanks,
Ben

[Joost de Valk (AlthA)]

Actually, the number there is the Safari build number, it is boosted more often then the safari version number, so could be used in situations where a bug is fixed and the Safari version isn't changed. Next to that, changing it would mean breaking lots of websites, so, this is a wontfix.

For information on which Safari version corresponds to which Safari build: http://developer.apple.com/internet/safari/uamatrix.html .

[Benjamin Derry]

I know it is the build number and that is the problem. That number may change more often and hence there is no pattern to it.

<RANT>
Other than saying this will break a whole bunch of sites. I say the opposite. That it will give sites the opportunity to qualify the production versions of Safari if they so shoose. Which before, with the build number instead of the version number, the site designers would have probably chosen not to support Safari because they would have to maintain a larger table of build numbers to qualify that product. Which normally they would have the major version number to go by.
</RANT>

<Discussion>
I work with an application called WebCT Campus Edition 6. Recently they released a new version called Campus Edition 6 SP1. On that version they list Safari 2 support. When I got around to upgrading our copy my Safari was at 2.0.3. They have a browser check function that kicks in right as your loging in. It said I didn't qualify. I asked them about it and they said that Safari used a build number instead of the normal version number and that is why they weren't going to fix it until the next Service Pack. Which is months away. Like most sites they don't care about the build number. They care about the major version number. Any subversions are relevant only when it affects their customers. Which in that case they would put an exception in their list and notify us through that browser checker.

Also if you look at the other modern browsers, I don't count IE in that list, out there they all conform to a standard of sorts on what that user agent string should look like. Hence making it easier for sites to use it.

Safari(2 parts wrong): en should be sn-US and Safari/417.8 should be Safari/2.0.3
Browser: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/417.9 (KHTML, like Gecko) Safari/417.8

Camino:
Browser: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060214 Camino/1.0

Firefox:
Browser: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Netscape:
Browser: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02

Opera:
Browser: Mozilla/4.0 (compatible; MSIE 6.0; Mac_PowerPC Mac OS X; en) Opera 8.5

As you can see they all conform to a standard of sorts. All of them have the same <application name>/<version number> string. Also as noted above Safari's string is wrong in 2 areas. And as far as the build number goes, you like everyone else already give the render library build number. Which is the one that would more than likely change more often than the Safari version number. Also I haven't seen Apple release a new version of Safari that didn't have its' version number upped.</Discussion>

<Feature Request>
Can you add support for changing this useragent string like Opera has. Would make my life a lot easier. :)
</Feature Request>

Thanks,
Ben

[Mark Rowe (bdash)]

The Safari version number in the user agent string is inserted by Safari, and thus is outside of the scope of WebKit.  Bugs in Safari should be reported at http://bugreporter.apple.com/.

As for the issue, I do not see how the Safari version number is any more useful than the build number.  Both provide information about which version of Safari is in use, with the build number being more granular than the version number.

Developers in most cases should *not* be checking the Safari version number, but should instead focus on the WebKit version number.  This allows them to support all WebKit-based browsers rather than just Safari.  

From a more practical point of view, changing the format will break any existing code that checks the version number of Safari.  I cannot see that being desirable unless it were to provide some huge gains.