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

I've been charged with figuring out how to do plug-in detection for a shareware animation plug-in, and though I have it working in Javascript on Netscape, I'm having a heck of a time with the VBScript version for IE. For that reason, and the fact that I don't want to make any assumptions about the user having client-side scripting turned on, I was hoping to be able to accomplish the same thing on the server side.

First I tried checking HTTP_ACCEPT to see what media types the client was accepting, but only came up with "image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*". I guess the plug-in's MIME type is somewhere under */*...

Then I tried using the CGI.pm module, 'cuz it says (and I quote)

Accept()

Return a list of MIME types that the remote browser accepts. If you give this method a single argument corresponding to a MIME type, as in $query->Accept('text/html'), it will return a floating point value corresponding to the browser's preference for this type from 0.0 (don't want) to 1.0. Glob types (e.g. text/*) in the browser's accept list are handled correctly.
Note the capitalization of the initial letter. This avoids conflict with the Perl built-in accept().

So this is the code I used:

#!/usr/bin/perl use CGI; $q = new CGI; print $q->header(), $q->start_html(-title=>'Plug-in Detection'), $q->Accept('x-animation/x-inkmorph'); $q->end_html();

I loaded the CGI on a browser that had the plug-in and got a result of 1. Sounds great, right? It was, until I tried it on a browser that didn't have the plug-in, and I still got a result of 1.

What am I doing wrong here? Or is server-side plug-in detection simply not possible? If anyone has any ideas, please let me know. Failing that, I could use some good VBScript links. :(

Thanks,
Michelle

Replies are listed 'Best First'.
Re: Server-side plug-in detection?
by Masem (Monsignor) on May 06, 2001 at 04:00 UTC
    You are trying to solve an impossible problem. As you observed, all desktop browsers report back that they access all data types, and will gladly suck down any data that you pass to them. In cases of plug-in data, that data would start the plug in, while in others, the user might be asked where to save the data or other means. There is absolutely no way via standard means to determine whether a plug-in exists on the end computer.

    The only browsers that I know of that will not accept */* mime types are some of the newer WAP browsers and a schmattering of text-to-voice ones, but nothing mainstream yet.

    Now, if this plug-in that you are using has a way to delieve content that allows a user to click a link to go elsewhere (Flash, eg), then you can use that as a way to 'guard' the rest of your site; if the user has the plug-in, they'll see the short animation, and you can instruct them to "click here" to continue. Those that don't have it will have no idea where the enterance is and thus will not visit the site.

    (My web ethics note: this is bad bad bad bad bad bad bad. 99% of the time, forcing the use of a plugin to delieve site contents is very very bad and not necessary. Plugin data should only be used to enhance the site's appearence and not hide content from users that can't use that plug-in. The 1% of the time where this is not the case are sites that are meant to demonstrate the abilities of these plugins. But this is my ethical opinion, and has no bearing on the tech answer above.)


    Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

      Ok, I guess it's back to the VBScript for me. At least for now... the animation plug-in in question is WAP compatible, so if there's a chance I can do server-side detection on (some) WAP browsers I'll have to look into it later.

      Thank you for your informative reply!

      Michelle