This may seem like a strange request but the reasons are too long to go into. Suffice to say it is a 'workaround' issue.
e.g. a user clicks on /path/file.exe?ABC or /path/page.htm?DEF or /path/anything and program Pearl1.pl is kicked off.
Important: ?ABC and ?DEF must be passed to Pearl1.pl in QUERY-STRING.
Tom
Any file that has the mime type application/x-httpd-cgi or handler cgi-script (Apache 1.1 or later) will be treated as a CGI script, and run by the server, with its output being returned to the client. Files acquire this type either by having a name containing an extension defined by the AddType [httpd.apache.org] directive, or by being in a ScriptAlias [httpd.apache.org] directory.
Note the ScriptAliasMatch [httpd.apache.org] directive.
<!--#include virtual="/cgi-bin/Pearl1.pl" -->
if the file is a static file (.htm) and includes are enabled for that type.
However, if you're running a script or a prog; you mentioned /path/file.exe?ABC, then you'll have to run that script from the .exe file.
Yes, the original query_string is available to your .pl script.
I don't know of any other way to kick off the script other than with includes.
I will pursue that option and see where it gets me if I understand it correctly (which I probably don't as I am a newbie at Apache and Pearl.:) )
bobriggs
The server is Apache. I use SSI includes in my static HTML for visitor tracking.
The .EXE files that my URLs point to are there for users to download. I am a software developer. They are not run on the server.
Tom
First, It's PERL or perl.
There are a few ways you can run a script for every request in a directory. One, is to name your script something that looks like a directory. In your example, call it /path. Then, when you call [example.com...] the script at /path will be run (it's not a directory, remember?). The query string will be what you expect, and the foo.html part will be in the PATH_INFO environment variable. All the other variables will be the same. You can see this for yourself by calling some script you already have installed with some more crap on the end. For example: [example.com...]
Another way is to redirect all URLs in the /path/ area to some other script. You stand the chance of losing some posted information or query_string depending on how you redirect the requests.
If you want to run this script and serve up a file that the URL refers to, then the best thing to do is probably to set up your perl script as a apache handler through mod_perl so that it will handle all requests to that directory (and send the file, or pass the request on to the normal handlers to deal with the file.)
Or, you can use the first method, and use the PATH_INFO variable to figure out which file to push to the client after the rest of your script has run.
I'm sure there are other ways, but these seem like the most common and reasonable.
"Another way is to redirect all URLs in the /path/ area to some other script. You stand the chance of losing some posted information or query_string depending on how you redirect the requests."
I wish I could as my total solution to my problem would be easier.
I have tried everything within my power to do the above, but I *cannot* get the query_string to be passed to the program. I have spent 2.5 weeks on and off.
I could have used mod_rewrite for my problem but I use FrontPage, so mod_rewrite and FP extensions clash on the server. (please take this as a given) WHAT A PAIN!
A guy who is helping me via email *can* get the query_string into his script, but I cannot, even when using the same .htaccess Redirect and same script as he.
I tried 'andreasfriedrich' solution and it worked! Thank you.
My .htaccess file in the problem directory will now contain
Options ExecCGI
AddType application/x-httpd-cgi .exe
The problem is that I have faulty /path/file.exe?qs in cyberspace that are too difficult to change. I will now make ALL my .exe files in the problem directory into scripts and push out correct URLs to clients.
Thanks all.
Tom