[webkit-dev] UA string changes blog draft
Mihai Parparita
mihaip at chromium.org
Fri Mar 25 11:04:41 PDT 2011
Hi Peter,
I think you should say "User Agent String" in the title and maybe in
the first paragraph say "User Agent (UA) string", so that it's not
quite as cryptic.
The inline URLs are a bit ugly, perhaps "some changes" could be turned
into a link to the tracking bug and "similar changes in Firefox 4"
could link to the mozilla.org post (and perhaps work in a link to
http://blogs.msdn.com/b/ie/archive/2010/03/23/introducing-ie9-s-user-agent-string.aspx).
> Here’s some sample post-change UA strings:
> Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.24
> (KHTML, like Gecko) Version/5.0.3 Safari/534.24
Presumably the U and en-u should be removed from this line?
The draft also has a lot of (presumably Google Docs-induced) inline
styles that it may be a good idea to clean up.
Mihai
On Fri, Mar 25, 2011 at 10:53 AM, Peter Kasting <pkasting at google.com> wrote:
> On Fri, Mar 25, 2011 at 10:50 AM, Peter Kasting <pkasting at google.com> wrote:
>>
>> I've created a draft blog post at http://www.webkit.org/blog/?p=1580 about
>> the recent changes I and others have made to the UA string. I'm interested
>> in any feedback you might have.
>
> Note, since this is a draft, you need to log in to blog.webkit.org to see it
> (creating an account is simple and free). For those who haven't logged in
> or don't wish to, here's the current fulltext.
> PK
> ---
>
> UA String Changes On WebKit Trunk
>
> Posted by Peter Kasting on Friday, March 25th, 2011 at 10:44 am
>
> Recently some changes to the UA string (tracked by
> https://bugs.webkit.org/show_bug.cgi?id=54556) have landed. These changes
> are designed to add UA string detail, remove redundancy, and increase
> compatibility with Internet Explorer, and are happening in conjunction with
> similar changes in Firefox 4 (which you can read about at
> http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/).
>
> Here’s a few sample pre-change UA strings:
> Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.19.4 (KHTML,
> like Gecko) Version/5.0.3 Safari/533.19.4
> Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.16+
> (KHTML, like Gecko) Version/5.0.3 Safari/533.19.4
>
> Here’s some sample post-change UA strings:
> Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko)
> Version/5.0.3 Safari/534.24
> Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_7; en-us) AppleWebKit/534.24
> (KHTML, like Gecko) Version/5.0.3 Safari/534.24
>
> In detail, the differences are as follows:
>
> On Windows, the initial “Windows;” platform identifier has been removed.
> This was redundant with the subsequent OS version identifier, and is more
> compatible with Internet Explorer, whose UA string doesn’t have this initial
> token.
> The “U” SSL encryption strength token has been removed. This token dates
> from more than a decade ago, when U.S. export laws limited the encryption
> strength that could be built into software shipped to various other
> countries; the valid values are ”U” (for “USA” 128-bit encryption support),
> “I” (for “International” 40-bit encryption support), and “N“ (for “None”, no
> encryption support). These days, it’s unusual to ship without 128-bit SSL
> support everywhere; ports can add “I” or “N” if necessary.
> On 64-bit versions of Windows, tokens have been added after the OS version.
> 32-bit builds running on 64-bit Windows have added “WOW64“. (”WOW64″
> stands for “Windows 32-bit On Windows 64-bit” and is the name Microsoft
> gives its 32-bit compatibility subsystem.) 64-bit native builds use “Win64;
> x64” for x64-based processors and “Win64; IA64” for Itanium systems. These
> tokens are useful for sites that need to provide download links for native
> executables, and match what Internet Explorer uses.
> The locale has been removed. Web authors who want to know what languages a
> browser supports should use the HTTP Accept-Language header instead, which
> can supply multiple locales.
> Windows CE builds should report the OS version slightly more accurately
> (e.g. “Windows CE 5.1” instead of “Windows CE 5.x” or “Windows 5.1“).
>
> Google intends to ship Chrome 11 with these changes, assuming they don’t
> cause major web compatibility problems, in order to get them into place as
> soon as possible after the Firefox 4 and IE 9 launches, and is already
> testing them in Chrome Dev and Beta channel builds.
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
More information about the webkit-dev
mailing list