First, let me say I'm by all standards an amateur, both in Perl programming and especially in SSI.
To illustrate the problem, I've put up a few test files on my site:
[fabulakreativ.no...]
The above is a small Perl script, looking like this:
------------
#!/usr/bin/perl
$?=1;
print "HTTP/1.0 200 OK\n";
print "content-type: text/html\n\n";
print "<p>This is a test of Server Side Include, using the #exec command.</p>\n";
------------
Lines 2 and 3 were added after reading some online article about IIS misbehaviour, so I included it to be sure that wasn't the problem.
If you follow the above link, you'll notice that the output works. The idea is that that HTML paragraph should be output into this page:
[fabulakreativ.no...]
... where I use this SSI directive:
<!--#exec cgi="/CGI_BIN/ssitest.pl" -->
But IT DOESN'T WORK! And it should! According to my ISP and other resources I've checked, this should be OK. But it isn't.
And I NEED to be able to include Perl scripts to do all the cool things I want to do on my site.
Can someone help me with this? Pleeease? What I'd like to know is, of course, what the problem is, and how to solve it. Failing that, I'll settle for what the problem might be and how it might be solved, or at least where it most probably lies.
This might not be your problem, but some hosts won't allow the use of SSI exec. You could try using
<!--#include virtual="/CGI-BIN//ssitest.pl" -->
Also, I've read that although IIS will allow exec in .html etc pages, you can't use it in .asp pages - although I believe this depends on which version of IIS you're using.
Did any of that help?
Thank you.
> This might not be your problem, but some hosts won't allow the use of
> SSI exec. You could try using <!--#include virtual="/CGI-BIN//ssitest.pl" -->
I tried that, but that only lists the contents of the Perl script (the code).
> Also, I've read that although IIS will allow exec in .html etc pages,
> you can't use it in .asp pages - although I believe this depends on
> which version of IIS you're using.
I tried that too, but that doesn't work at all. My ISP (ActiveISP) requires that you use .asp with all SSI -- at least that's what they say, and apparently that's how it works, too.
So, no luck for me yet. Any other suggestions are very welcome, as this is slowly but firmly over the edge...
Did you get it to work? You are on a Windows box, right?
Unfortunately, I know more about cooking than Windows boxes (that's not a good thing), but can you (I am asking here - not telling) modify your .htaccess file with things like...
EX:
Options Includes +ExecCGI
AddHandler server-parsed .html
and that sort of thing?
I exit... apologizing profusely for my ignorance. I'm just curious about this.
Idiotgirl
And no, it still doesn't work, and I have tried a number of other things, too.
<!--#include virtual="/CGI-BIN//ssitest.pl" -->
should be:
<!--#include virtual="/CGI-BIN/ssitest.pl" -->
i.e. no double slash.
<added>
Just noticed you had CGI_BIN not CGI-BIN, so actually, it should be:
<!--#include virtual="/CGI_BIN/ssitest.pl" -->
</added>
I wrote back to the web host again, essentially telling them I was pissed of with them and about to demand my money back and go looking for someone else. That apparently got them moving.
And it was the stupidest little thing, too, that the web host really should know about. According to my ISP, .asp doesn't support all SSI directives, among them #exec. The simple solution was to use .shtml instead.
Although I'm extremely annoyed that the solution was that simple, that the host didn't know that right away and that it has taken them 3+ months to dig it up, I'm mostly relieved and happy that it's finally working. Now I can go ahead and make all the little nifty things I've only been able to dream about up until now. :-)
Another way to fix this(more preferable to people with existing web pages), which will increase processor usage, is to go into the "Home Directory" tab or "Directory" tab under the Properties dialog box of your "<Default Homepage>". This can be found under control panels->Administrative Tools->Internet Services Manager on Windows 2000. When you've located the Directory tab, click on Configuration. It is located near the bottom of the dialog box. The list of applications or extensions associated with them is where you will find the files that IIS WILL parse before sending to the browser. You will notice that .htm and .html are not in the list(as they always have been on previous versions to the best of my knowledge). However .shtm and .shtml are listed and associated with an iis dll file. Make a duplicate of the .shtm and .shtml files but with .htm and .html instead and now your webpage, no matter what the extension is on the end, will be parsed, or in other words searched for #include and #exec commands.
It will react the same way it did on the old IIS servers, i.e. the ones before IIS 5.0. This seems to be a change that microsoft implemented in IIS 5.0. They say it is for processor speed, but we all know it is to make people get exhausted trying to use cgi, and decide to convert everything to asp(their pride and joy).
To add my theory on why an asp file cannot have cgi included, remember how it works. Asp files are parsed just like .shtml files. For .shtml files, IIS looks for #exec commands and then tells the IIS dll to process that...who in turn executes the cgi. The asp files talk to a different dll file though, an asp.dll file. Therefore, inside the asp.dll, executing external programs has been disabled. Microsoft considers running external programs, and valid in thought, a way of introducing a security risk. Hope this helps with confusion(preferably helps with easing it and not introducing it), I've learned a lot today!
