gri6507 has asked for the wisdom of the Perl Monks concerning the following question:

I have a need for detection of browser capabilites. In particular, if anyone has used HM_Menues, that JavaScript needs to be particular to whichever browser is used to view the page. So here's my problem. The CGI script needs to detect which borwser is used (IE4, NS4, or DOM according to HM_Menues terminology), and write out the appropriate JavaScript. Here's my code so far:
if ($ENV{'HTTP_USER_AGENT'} =~ /MSIE/){
  #it's IE
} elsif ($ENV{'HTTP_USER_AGENT'} =~ /Netscape/){
  #it's Netscape
}

[download]

This, however, never detects Netscape (I checked it with Netscape 6.2). Any suggestions? Also, what exactly is DOM (see above for reference).

Replies are listed 'Best First'.
Re: Detecting uers web browser in CGI script
by little (Curate) on Jan 23, 2002 at 23:41 UTC
    You might want to look at HTTP::BrowserDetect.
    And here is why you should: You will need to check for the string "Mozilla", as this is how they (IE and NS) show up as , if found determine if its an IE or a thing that calls itself "gecko". There are plenty of User_agents out there and I am sure a google search will quickly turn up a list of about 50 different strings that those different browsers present to identify themselves, but you might get stuck as the MSIE ADMIN kit allows for customisation which affects that string in your severlog as well, recently I've seen one MCK, which stood for McKinsey.

    Have a nice day
    All decision is left to your taste
    Update :
    The W3C is your friend regarding all things and links about Document Object Model (DOM).
[reply]
(jeffa) Re: Detecting uers web browser in CGI script
by jeffa (Bishop) on Jan 23, 2002 at 23:40 UTC
    Quick answer is check for Mozilla instead.

    But just in case that is wrong, write a little script like this: 

    use strict;
use CGI qw(header);

print header(), $ENV{'HTTP_USER_AGENT'};

    [download]
    load it in the appropriate browser and record the results.

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]
[d/l]
Re: Detecting uers web browser in CGI script
by ViceRaid (Chaplain) on Jan 24, 2002 at 18:59 UTC

    Yep, see the answers above give you a good answer for how to detect a User Agent on the server side. However, as a rule, I think that handling compatability of scripts and styles is much better done on the client side. So, instead of having your cgi write a different line into the web page for Netscape and Internet Explorer, use Javascript to pull in different scripts for different browsers. In Javascript, you can query the navigator object for information about the user agent, and then use this information to link in different stylesheets or external scripts. eg:

    if ( document.layers ) {
   document.write('<link href="/path/to/netscape_style.css" rel="Style
+sheet" type="text/css">');
}

    [download]

    Why? Well, firstly you can find out more information on the client side than is available on the server - for example, CPU class, OS, or screen resolution. This is particularly useful as Internet Explorer is really quite different in capabilities between Mac and Windows.

    But the biggest reason is caching. I got burnt on this once before - we wrote a large content-managed site which had been designed with different stylesheets and Javascript for IE and NN4. We handled it on the server side. Then we got to deploying the site on the client's machines, and we discover that the webserver is going to be sitting behind Squid, a caching proxy. Our application rendered the pages on request, then they'd be stored for 6 hours unchanged in the proxy. So, let's say the homepage was rendered for Netscape - oops, then all IE visitors got the NS version from Squid, and it was broken. oops. We had to re-write to do browser-checking on the client side, as above.

    OK, in this example, we did know about the proxy eventually, and could control it. However, proxies are ubiquitous, and you won't know about or be able to control most of them. It'll be much nicer if your page and Javascripts work well even when they've come from a reverse caching proxy, through a company proxy, or get served from Google's cached copy. It won't work if you do browser compatability server-side, but it probably will if you do it in the user's browser.

    As an aside, the W3C DOM is a very good thing. Being able to write once for NN6 and IE5, and having Javascript do what it says on the tin has renewed my enjoyment of client-side programming. Open Directory has a bunch of useful links to tutorials and examples which are a bit less dry than the straight W3C recommendations.

    a
[reply]
[d/l]
      Actually, this entire question arose because I could not use Javascript. Due to the infinite wisdom of the server administrators, I was forced to output the entire page with my CGI script. However, i still needed to have the javascript component in the page.

      To be more specific, the way this HM_Menues stuff works (see above) is be executing one JavaScript which detects the browser, and, depending on the outcome, loades another JS (IE4, NS4, or DOM). If you can think of an easier way of doing this from a CGI script, I will gladly accept your suggetsion.

      Thanks.

[reply]

Back to Seekers of Perl Wisdom