Weird IE7 User-Agent string
Well, this is about the Browser Detection Script.
On Windows XP with IE6 I had installed IE7. But what is (now it isn't) strange that the script detects IE7 as IE6. How come... The trouble isn't new: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ) As it is commented at the bottom of the script: :: Code :: // there are some cases of double msie id's, first in string and then with then number
//this test covers you for multiple occurrences of string, only with ie though So my solution is to get the first occurance: MSIE 7.0 :: Code :: if (preg_match("/msie 7\.0/i",$browser_user_agent) && preg_match("/msie 6\.0/i",$browser_user_agent)) {//shimansky
$browser_number="7.0"; } elseif (preg_match("/msie 5\.5/i",$browser_user_agent) && preg_match("/msie 6\.0/i",$browser_user_agent)) {//shimansky $browser_number="5.5"; } elseif (preg_match("/msie 5\.01/i",$browser_user_agent) && preg_match("/msie 6\.0/i",$browser_user_agent)) {//shimansky $browser_number="5.01"; } However, this is obviously not comfortable. So, what would you recommend? Oh, by the way, the matrix-style of the code field is very hard to read, IMHO. Thank you for your script: it does a lot of work on my site. Back to top |
|||||
Your question is unclear.
Here is a native MSIE 7 XP SP2 user agent string: :: Code :: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) No changes, this is a vanilla install, with msie 7 upgraded from 6. So it sounds like you have some very specific issue which isn't related at all to the script, unless I'm missing something. I try to avoid those cascading number tests, because ideally the script should not require manual updates for browser number versioning. It sounds like maybe you are running 6 and 7 together? Anyway, I can't say, whatever you're seeing on your system appears to be unique. How to fix your single case I can't really say, usually I don't spend much time if it's a unique case. :: Quote :: the matrix-style of the code field is very hard to read, IMHOI'm not sure what a 'matrix style' refers to, the code field is pretty standard style. I assume you're using a real code editor, with syntax highlighting and all the other features? If not, time to upgrade to any one of a number of free or non-free editors. Crimson editor is a nice free one. In free operating systems, linux or bsd based, kate/kwrite is pleasant. I will happily admit that the script got a bit long over the years, but since it never really requires tweaking after it's set up, except for rare bug fixes, I've never worried about it. Back to top |
|||||
The question is quite clear. The doubling of user-agent-string after installing msie7 (the installer taken from Microsoft site). So the script takes second occurance and thus presenting msie7 as msie6.
:: jeffd wrote :: So it sounds like you have some very specific issue which isn't related at all to the script, unless I'm missing somethingYes... but now it is related. Hum I'm not asking for rewriting the code. I'm just showing the trouble and the solution. By matrix code I ment the appearance of the bbcode's CODE tags: green on black is hard to read. I'm not asking for editor. By the way for PHP I use Blumentals RapidPHP, for Javascript - 1st Javascript Editor and for textfiles array tables NoteTab Light. Also a very good editor - Programmer's Notepad, which is free. Your answer sounded too bureaucratic. No-one's trying undermining the script, which is clearly read in your reply. Back to top |
|||||
Ah, ok, I really had no idea what you were talking about re matrix code, that's an incorrect use of the term matrix I believe.
Re the colors, I guess it's subjective, for me, reading green on black is easy, and other common code box colors are hard. That's why I use green on black in terminals too, but since it's subjective, it's just a matter of making some of the people happy some of the time, I can't make everyone happy all of the time. So my response was just a guess re what your question was, sounded like a code editor related thing, but if it's just a matter of CSS color selection, which is what the [ code ] boxes set, that's fine, the colors and fonts have to be something, so they might as well be something we like... However, the original question is still unclear, as I noted, my test xp had the ie 6 upgraded via windows update to ie 7, and does not show such an anomoly. Are you saying that you downloaded the actual full msie 7 installer executable, ran it, and it shows this? Did you keep your msie 6? Some configurations, like browsers.evolt.org, let you have strange msie setups, but I don't really know any safe way to handle both your exception and the standard msie 7 user agent safely. What makes it more difficult is that both occurances use msie compatible in their strings. The solution you posted is not something I'd use personally, although of course, you're free to modify the code as much as you want for yourself. I gave up on such static methods a while ago, I prefer more dynamic detections that work for pretty much all cases. If you think of something that would handle your case and the standard, without hard coding in detection numerical values, let me know, and if I think of one, I'll implement it, easy enough to test and debug with firefox user agent switcher. Let's see what the official user agent strings for msie 7 are supposed to look like, from the msdn blogs: :: Quote :: A quick recap:
* On Windows XP SP2, IE7 will send the following User-Agent header: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) * On Windows 2003 Server, IE7 will send the following User-Agent header: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2) * On Windows Vista, IE7 will send the following User-Agent header: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Here's another page with long lists of possible MSIE 7 user agents As you see, there is no doubling in any case. My guess is that something didn't go right in the install, that also happened to me once when I was upgrading a friends MSIE from 5 to 6, the information field insisted it was MSIE 5, even though it was in fact 6. You can edit your registry to correct this error in your user agent, I can't remember the exact path, I think it's hkey local machine -> software -> microsoft -> internet explorer, or something like that. Back to top |
|||||
Oh yes. browsers.evolt.org - I use their packages of IE - 6.0 5.5 and 5.0 So I'll have to dig the registry, i suppose. Many thanks.
Yes. It's there: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post Platform And the key NAME is : Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) TYPE: REG_SZ VALUE: (empty) - DELETED and here: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent ADDED: Mozilla/4.0 (compatible; MSIE 7.0; Win32) So now the script says 'IE 7.0 NT 5.1' FINE But this happend (the doubling). So I'll have to keep my changes to the script: I'm not the only one, I guess. Thanks for your help. Also I should add that the Browser Detection Script is used widely by myself. And not only for swithcing CSS, but for security purposes. For instance, if visitor's BROWSER (the script) and HTTP REFERER (php) don't get detected, there's no chance for him to carry on. Goes without saying that your bots like ATOMZ should be added to the array. As for Linux, in Russia, even Moscow and St. Petersburg visitors 'sit' on WINXP using IE6/7. It's a delicious thing to strike upon a unix visitor. As I can recall, one visitor per two days comes from LIN. I use Fedora 8 in pair with WINXP and WINE stuff is to be exploited. PS: :: Quote :: 01:55:05
XXX.hsd 1.ca.comcast.net [?] XXX [?] [?] [?] [+] KONQ 3.5 LIN DEBIAN from: xxx to: xxx /home.xhtml Access denied for REFERER:/HOST: \.comcast\.net. Data: data/spam_referers.d at. Sorry, comcast visitors are banned, for there are too many spammers from this host < Edited by englishextra :: May 28, 08, 14:29 > Back to top |
|||||
now it makes sense, glad evolt was mentioned, I used to use that stuff all the time, running multiple msie's is always fun, though now I do it in linux with wine, and in virtual machines, one browser per machine, to avoid the exact types of problems you had, the emulation stuff just never works quite right for testing and debugging.
Look into vmware, you can get msie 5 and 6 running fine in two windows 2000 installs, and with xp, you can get 6, 7 and 8, running, in 3 installs. I recommend vmware because it lets you easily clone OS installs, virtualbox, which is otherwise very pleasant, doesn't let you clone installs. Back to top |
|||||
A useful addon for Firefox that can switch user-agent string to anything you customize can be installed here: addons.mozilla.org/ru/firefox/addon/59
Bad news about that addon is that the CSS is still rendered by Mozilla engine. So you can only test the Browser Detection Script output, not CSS. Also please notice that each time you launch a standalone version of old browser (see discussion above) downloaded at browsers.evolt.org/ the user agent-string is changed at: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post Platform to (initially empty): 'Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)' as a registry key name - not value, which ends up in this weird string (for ie7 on Windows XP SP2, e.g.): Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ) Back to top |
|||||
IE8 browser string issue
First of all, thanks a lot for this great function :-)
I'm running a website with a lot of ajax stuff on it. I have decided to ignore IE6 compatibility. So, I'm displaying a error/warning message to all IE6 users using the browser detection script. However, I've got some complaints from users, because they are surfing with IE8 - but they were receiving the IE6 warning. I've debugged this very strange problem an noticed, that their browsers were sending an odd HTTP_USER_AGENT string. One of them was: :: Code :: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0; GTB6.3; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)Ok, the first MSIE 7.0 says, that this IE8 browser is running in compatibility view (Trident/4.0 = IE8). The second string (MSIE 6.0) comes probably from a browser plugin. As it seems, this is an old problem. I've found more information about this issue on this website: [link] The browser detection script seems to know this issue too. Inside the function :: Code :: function get_item_version()it says: :: Code ::
// there are some cases of double msie id's, first in string and then with then number $start_pos = 0; /* this test covers you for multiple occurrences of string, only with ie though with for example google bot you want the first occurance returned, since that's where the numbering happens */ in the browser string above, the correct browser number should be MSIE 7.0 - but the function returns to me MSIE 6.0. this is because of this on line 737: :: Code :: if ( $pv_search_string != 'msie' )
{ break; } With this code, it always takes the last occurrence of the MSIE string. It seems like that is done on purpose. But I can't figure out why? IMHO that loop for multiple occurrences is not really needed? Maybe this double-string issue, the author is pointing to, is a very old behavior from IE4 or IE3? But I have also checked old IE useragent strings here: [link] - unfortunately, that also didn't gave me anymore clues. For all other browsers than MSIE, it takes the first occurrence, which is correct - and should be also done with IE browsers. I believe this is a bug? I have now updated my code as followed: :: Code ::
/* bugfix - code removed for ( $i = 0; $i < 4; $i++ ) { //start the search after the first string occurrence if ( strpos( $pv_browser_user_agent, $pv_search_string, $start_pos ) !== false ) { //update start position if position found $start_pos = strpos( $pv_browser_user_agent, $pv_search_string, $start_pos ) + strlen( $pv_search_string ); if ( $pv_search_string != 'msie' ) { break; } } else { break; } } */ // code added $start_pos = strpos( $pv_browser_user_agent, $pv_search_string, $start_pos ) + strlen( $pv_search_string ); // EOF bugfix This works perfectly well. Now it gives me the right browser version in IE and any other browser. IE8 Detection (Trident/4.0) Will the IE8 "trident" token be included in further versions of the browsers detection script? Maybe this information could be useful for some applications? Thank you for looking into this matters :-) Back to top |
|||||
It's not a bug, there are instances, too often, where poorly written msie plugins and tools insert a second MSIE into the single user agent string.
First, thanks for posting all the relevant information, and for searching the forums for information. However, thanks for alerting me to this issue re the trident/4.0 Also, removing the test if in string is not a good idea as a patch, it leads to unpredictable failures, as I discover every time I forgot to test for that. The case you listed with the twin user agents is not really something the browser detection script covers since it's an error, in my opinion. So you are right, taking the last instance IS done on purpose, because all the user agents we saw that had been mutilated by bad msie plugin software placed their gunk prior to the real msie version. msdn information on the trident part: blogs.msdn.com/ie/archive/2009/01/09/the-internet-explorer-8-user-agent-string-updated-edition.aspx :: 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) From what I can see of various such user agent strings: :: Code :: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; FunWebProducts; Comcast Install 1.0; GTB6; .NET CLR 1.1.4322; .NET CLR 2.0.50727; MSN OptimizedIE8;ENUS)
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; OfficeLiveConnector.1.3; OfficeLivePatch.0.0) The solution here is to scan FIRST for trident, then to take the FIRST instance of msie if trident is found. That does not break the existing patches for other systems, and it covers the msie 8 in compatibility mode case. Back to top |
|||||
The other option might be to search for Trident/, not sure, have to think about it. An explicit hack might be better in some ways.
Back to top |
|||||
All times are GMT - 8 Hours
|