Browser Detection Scripts - IE8 detected as IE6
deny
Status: Curious
Joined: 04 Jul 2008
Posts: 6
Reply Quote
IE8 has been released today and it comes to my attention that IE8 has been detected as IE6.
Hopefully new browser detection scripts will be released soon to fix this issue.

This is IE8 string on Vista
:: Code ::

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; http://bsalsa.com) ; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618)

Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
Please take a moment to review the user agent string you posted:

:: Code ::
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; http://bsalsa.com) ; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618)


Note that it is seriously corrupted by the embedded bsalsa.com string:
:: Code ::

User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; http://bsalsa.com) ;


the browser detection script is not smart enough to handle corrupted user agent strings, I suggest you file a bug report with bsalsa.com.

My guess is that bsalsa embeds that string into the standard msie string, which I tested, after removing the buggy bsalsa code:

:: Code ::
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618)


and which then works exactly as expected.

In general I think it's a bad idea to change highly stable and heavily tested code to handle what is a bug in a tiny niche of the market.

I believe what Windows does is have its useragent string in registry, then a thing like bsalsa injects its own user agent string into that, forming an amalgamated string, mutated and essentially broken, and for data collection purposes, largely useless, unless you are looking specifically for bsalsa stuff, whatever that is.

But thanks for the possible bug report, all are taken seriously, even if they are caused by something unrelated to the browser detection script, as is the case here.
Back to top
deny
Status: Curious
Joined: 04 Jul 2008
Posts: 6
Reply Quote
The problem is that it is official released version of IE downloaded from windows site:
www.microsoft.com/windows/internet-explorer/default.aspx

I understand that it is probably bug but visitors should do not understand and this bug will be displayed to 100% of IE8 users.
It will be better to find some way around this bug because i do not believe that there will be something changed in future to solve this bug from Windows or bsalsa
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
I disagree with your assessment, that user agent string is most certainly, as I said, the result of that bsalsa thing running in your system.

Again, what occurs is that internet explorer has a user agent string listed in windows registry. That bsalsa thing, which is most definitely NOT a part of windows anything, is injecting its useragent string in after the fact, this is unrelated to windows at all, and is just a bug with that thing.

This isn't related to end users at all, unless your end users all use that bsalsa stuff, whatever it is.

However, since it appears you don't believe me, hopefully you will believe blogs.msdn.com MSIE 8 user agent strings.

:: Code ::
IE8 on Windows Vista (Compatibility View)

    Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0)

IE8 on Windows Vista

    Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0)

64-bit IE on 64-bit Windows:

    Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Win64; x64; Trident/4.0)

32-bit IE on 64-bit Windows:

    Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0)

Incidentally, WOW64 stands for “Windows on Windows 64-bit.”


This issue is in your computer, not in general user's computers, and it's a bug with the user agent string that bsalsa is sending out, that bug needs to be handled by bsalsa, not this script, I've never even see that product in the wild in 10 years, although I'm sure it exists, of course.

The: SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618)
part of your string is caused by a few other addons, and are standard, and do not cause problems, because they are done correctly.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
However, if you want this bug fixed, then I suggest you modify the user agent string detection function to search for bsalsa in the string, and if found and present, to use only the first instance of msie detected. This type of super precise customization is outside of the scope of this script, which is designed to work everywhere, dynamically extracting browser data without requiring manual hacks. This works very well, as long as the string is not corrupted as it is in your sample case.

In pseudocode, what you do is this: in the browser version function, you search the full string for bsalsa, if found, you change the value of the loop to 1, ie, and then make it exit then, which should make it grab the first occurance of msie, 8, and exit prior to the second, 6. However, once you look at that function, you'll also note that it handles a special case for msie already, not to exit on the first found, that's to handle various msie cases where it had the old compatible with first, then the true version second, but newer msie's don't do that. You could make it exit there if the string contains bsalsa as well, break, that is, but again, that's just something for you to play around with, just test for stristr bsalsa if there break at first iteration


The only time I'd think about adding in custom handling is if the msie default, correct, uncorrupted string, was actually also containing two instances of the msie version number, which of course it does not.

I won't add this to the primary function because it's not a general issue, and is caused by an external bug in a tiny niche of the userbase.

Cases like this are when you want to take advantage of the GPL's clear suggestion that all GPL code is free software, which you are free to modify to fit your own purposes.
Back to top
deny
Status: Curious
Joined: 04 Jul 2008
Posts: 6
Reply Quote
You are right. I have found and removed bsalsa from registry.

Thank you for your time
Back to top
Mangled IE8 strings
dieselmachine
Status: New User - Welcome
Joined: 20 May 2009
Posts: 1
Reply Quote
I have the following useragent showing up in our logs, and due to the double compatible thing, it has been blocked.

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; SLCC1; .NET
CLR 2.0.50727; InfoPath.2; .NET CLR 1.1.4322; .NET CLR 3.5.30729; .NET CLR 3.0.30618; OfficeLiveConnector.1.3; OfficeLivePatch.0.0)

I posted here because it seems very similar to the above UA, but without the bsalsa. Can someone tell me, is there any legitimate way this UA could ever come into existence?

In addition, the user claims that the browser he is using is IE6. Is this actually IE8 trying to masquerade as IE6 using registry hacks?
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
Impossible to know, as noted with the above, what a user has done to their system without realizing it by installing some odd tool that was written incorrectly and breaks the registry information is pretty far out of any league we can be in.

Also note it's impossible to test for this, since we have no way of knowing which is the real and which is the bad one, it could be the inner one, or the other one, it's totally random, since it's the result of a programming error in the first place.

However you have a good hint there: OfficeLiveConnector.1.3; OfficeLivePatch.0.0

Personally for my own sites, I never use ie detection except for msie 4, I use the msie conditionals, which are I believe always correct in terms of the browser respecting them, as long as it's msie >=5, at least almost always.

As you can see from the corrupted string, either the user is running xp with msie 6, or he is running vista with msie 8. So you can figure out which for sure by just asking them what operating system they use, vista or xp. Most people know that. The extensions there clearly embedded a false set of data.
Back to top
Display posts from previous:   

All times are GMT - 8 Hours