[Webkit-unassigned] [Bug 7342] User Agent string not conforming to standards.

bugzilla-daemon at opendarwin.org bugzilla-daemon at opendarwin.org
Mon Feb 20 07:59:57 PST 2006


http://bugzilla.opendarwin.org/show_bug.cgi?id=7342


ben at n9vpu.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|WONTFIX                     |
            Summary|User Agent string not       |User Agent string not
                   |correct.                    |conforming to standards.




------- Comment #2 from ben at n9vpu.com  2006-02-20 07:59 PDT -------
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


-- 
Configure bugmail: http://bugzilla.opendarwin.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list