I am a developer at Sane Solutions, makers of NetTracker [a web server log file analyzer]. Among other things, NetTracker parses the User-agents found in server log files to report on the platforms used by visitors to the site. The recent changes made to the user agents on Windows NT breaks our currently shipping products, as well as products made by some of our competitors that I tested. In particular, the OS/CPU values of "NT3.51" and "NT4.0" [lines 613 and 616 of mozilla/source/netwerk/protocol/http/src/nsHTTPHandler.cpp should be changed to maintain backwards compatibility. Please consider changing them to either "Windows NT 3.51" and "Windows NT 4.0" (which is closer to the user-agent reported for Windows 2000 "Windows NT 5.0"), or "WinNT3.51" and "WinNT4.0" (which is closer to the user-agents used in Nav 4.x). Either of those User-Agents work correctly with NetTracker and the competing products that I checked, but "NT3.5" and "NT4.0" do not.

Thanks for this information! I think we had assumed that the scripts looked just for "NT" or "98" since that was the only part we had in common with IE. Eric -- is this something we need to or even can fix for beta1? (nominating for beta1) It would be better to get people sniffing the right way from the get go.

To what level does this break you analyzer? What is the risk to fix? We can live wih wrong stats for OS, but not for Seamonkey.

It breaks the OS stats - not only in our product, but in that of our competitors as well. Not fixing this will cause a minor headache for just about anyone using a log analyzer. I also suspect that, in addition to log analyzers, some sites that use JavaScript to sniff the user-agent will be broken. I'm not the first person to ask for a change to NT identifier. Please see the various patches submitted for http://bugzilla.mozilla.org/show_bug.cgi?id=27745. To quote Eric Krock from news://news.mozilla.org/38BEC322.84833FC1@netscape.com, "Where past Navigator clients have already defined an identifying string for a given OS, we should preserve backward compatibility with that in Mozilla-based clients. Introducing new backward incompatibilities and breaking existing client sniffers will not help our customers (either the developers or the users)." Navigator 4.x reported Windows NT as "WinNT", not "NT4.0".

Woops, the link to the patches should have been http://bugzilla.mozilla.org/show_bug.cgi?id=29438. Sorry.

Since just platform and not product. Putting on PDT- radar for beta1. Not enough time, too risky for beta1.

=> Jud

Adding Jerry Baker, who kindly supplied the WinNT 3.51 and WinNT 4.0 patches, to cc: list. Jerry, could you please work with Frank & Jud to make sure we're backwardly compatible with past Navigator behavior, even at the cost of losing additional information if that's unavoidable? One of these compromise solutions may be possible, in descending order of attractiveness: 1) use "WinNT3.51" and "WinNT4.0", which should be backwardly compatible with Nav4 via the "substring presence test" for detection (e.g. indexOf("WinNT") in JavaScript) while also providing the additional information of whether it's 3.51 or 4.0 as an enhancement 2) on WinNT 3.51 and 4.0, we place in the UA string both the old Nav4 substring "WinNT" for backward compatibility and the additional substrings "WinNT3.51"/"WinNT4.0" or "Windows NT 3.51"/"Windows NT 4.0" to provide the additional distinguishment as an enhancement 3) For backward compat at the cost of specificity, last resort would be to return "WinNT" on both 3.51 and 4.0 Also, here are my full comments from the newsgroup: Here's my prioritized take: #1: Where past Navigator clients have already defined an identifying string for a given OS, we should preserve backward compatibility with that in Mozilla-based clients. Introducing new backward incompatibilities and breaking existing client sniffers will not help our customers (either the developers or the users). -- Example: Whatever we used in the UA string to identify Win95 in Nav4, we should obviously continue to use. #2: For new OSs, if a new IE client happens to ship on that OS long enough prior to Mozilla's ship date that we're able to use the same string, and if IE provides a string in their user agent string that uniquely identifies that OS, we might as well use the same string to achieve cross-browser compatibility. Creating gratuitous cross-browser incompatibilities when we don't have to benefits no one. -- Example: "Windows NT 5.0" uniquely identifies Windows 2000 in IE, and Netscape has never had its own string for this in the past, so we might as well use the same string. #3: If there is an older OS for which neither Navigator nor IE ever defined a uniquely identifying string, then Mozilla might as well provide a uniquely identifying string as an enhancement on the margin to our client-sniffing precision. -- Example: If in fact neither Navigator nor IE ever defined uniquely identifying strings for Windows NT 4.0 or 3.51 and they both just reported "Windows NT", then it probably shouldn't hurt to make the Mozilla UA report "Windows NT 4.0" and "Windows NT 3.51" respectively, because that string is both backwardly compatible with "Windows NT" (containing it as a substring) while also providing more precise information for those who wish to check to that level. [Implicitly, I'm assuming here that client sniffing is being done by uniquely-identifying-substring presence/absence detection (e.g. JavaScript indexOf()), which I believe to be by far the most common technique. If a sniffer did something more elaborate like locate the start of the OS substring and then scan forward to the next semicolon, then such an enhancement could cause problems. However, in the specific case of Windows NT, as it's been historically a relatively low-volume server/high end-focused OS compared to the consumer OSs, I doubt many client sniffers were ever written to check for Windows NT in particular at all, let alone to use this kind of more-elaborate and fragile technique, so I say we patch it and see if we get any feedback on it.]

clearing PDT- for another look. the code change to the client is trivial (once we settle on the strings to use). I think if we leave this as is, we'll upset a lot of sniffers and cause sniffer writers to start accommodating our "new" strings.

My first choice would be "WinNT3.51" / "WinNT4.0", as it works for my app and the others that I have tested. It also works for people sniffing for the substring 'WinNT'. My second choice would be just 'WinNT'.

Agree with Frank: "WinNT3.51" / "WinNT4.0" is the way to go. Agree with Jud: We should fix this for beta1. Here's why: - beta1 will have high visibility in the industry for two+ months - loggers will begin tracking usage and start modifying their software to track our "new" strings as Jud mentions, only to have to change it back - JavaScript client sniffer and server-side client sniffer code writers will also begin to sniff for our "new" strings, only to have to change them back too - we have clear feedback from an expert on this (Frank) that the change we're making is the right one - it is zero risk (we're talking about changing a hard coded string from one value to another!) Of course this should be robustly reviewed as we could survive without it, but please let's just get this in in the interest of not confusing our client and server-side developers. Getting it right the first time is a good thing.

can someone please take a look at the diff and give me a review it?

I have a new patch that will do this *and* handle all unkown future Windows versions in an intelligent manner. This way, users that still use old products (like we see with users of Windows 2000 using anything before 4.72, Windows 98 before 4.05, etc.) will not have their OS defined as something it is not. Stay tuned for attachment (can't make a comment and attachment at the same time).

someone pelase review my patch, I had a hard enough time getting approval for it, we can't take any more risk at this point. if we need to handle somehting else please open a new bug.

valeski's patch r=dveditz

We should follow Jerry's advice/patch *after* beta to make the naming scheme automatically extensible on windows. But it's not the right thing to do *today* given the pre-beta boa-constrictor grip on the tree. It would be easiest if that were a different bug so this one can be closed and tested for beta.

Patch looks good to me. Thank you for changing this!

fix checked in

Putting on PDT- radar. Should fix not take, we will not hold beta1 for this.

verified: NT 2000042009

Mass removing self from CC list.