Server Side Includes not working

I'd been hearing all the benefits of using SSI, but I was reluctant to change because printing out JavaScript in the Perl script was working just fine. But now, I've finished designing the site and now I'm going back through and improving things, like using CSS in order to easily change the way the entire site looks. Anyway, since SSI is a better (and more certain) way of doing things, I decided to change. The only problem is that it's not working. I'm using the Apache-httpd server and I made all the changes this book I'm reading said, but it still doesn't work. Firstly, here's what I put in my HTML page:

I changed hits.pl to just use print instead of printing out in JavaScript.

Actually, when I was going through the httpd.conf file, Apache seemed to have everything I needed. It already had the

directive set in the <directory> section and it told me to uncomment a section of code that looked like:

but my book said to do this:

Now, I'm thinking that this last part isn't even that crucial because I don't even have any .shtml files (not exactly what I need them for anyway) because I'm just try to execute Perl files from HTML pages. Also, I've seen to ways of doing what I want to do. Which way is correct, the one I have above or this one?

I even tried using #flastmod thinking that there could be a problem with the Perl file itself, but that didn't work either.

I also have a couple more questions:
1. Do I need to print the HTML header in the Perl file or do I just print out whatever I need w/o the header?
2. My book specifically says not to have any space between <!-- and the # sign, or between the closing quotation marks and -->, but in the examples on the Apache website they do have a space between the closing quotation marks and the -->

I guess that's it. Anyway help is greatly appreciated.

You need to either use a .shtml file or change

AddHandler server-parsed .shtml

to

AddHandler server-parsed .shtml .html # (.htm .shtm, whateve ryou want)

1) Yes.
2) Both should work.

>> Options Includes ExecCGI

Where (which <Directory>) did you put that? Keep in mind, a ScriptAlias'ed cgi-bin can't have any Options set.
For example:

ScriptAlias /cgi-bin/ "/www/cgi-bin/"

Then:

<Directory "/www/cgi-bin">
Options None
AllowOverride None
</Directory>

If your cgi-bin is simply a subdir under your docroot, then you need Options ExecCGI either defined in <Directory "/path/to/docroot"> or <Directory "/path/to/docroot/cgi-bin'>.

I'm fairly sure I put the "Options Includes ExecCGI" part in the right place, because I didn't even have to do it. That part was already done in the httpd.conf file inside the docroot <directory>.

Okay, now I'm understanding the need for .shtml files. I really wasn't getting it at first. But there's a problem with changing all the HTML files to SHTML files. First of all, my main page (index.html) has lots of places where I used <script src="perfile.pl"></script> (and then in the Perl file I display JavaScript) and I want to change to a SSI because JavaScript isn't always reliable. The reason this is a problem is when I go to cmc.rice.edu/docs/, it automatically goes to index.html. Will the same work for index.shtml? Or better yet, how would I change it in apache to look for index.shtml after looking for index.html?

Secondly, I create a lot of HTML pages using Perl. And at the top, I includes something like <script src="logged.pl"></script> and at the bottom I do <script src="footer.js"></script>. The first I would execute a Perl script and the second I would just include an HTML file. Anyway, what type of file is this considered to be? Technically, I think, it's a Perl file, right? Or is it an HTML file? And if it's an HTML file, how would I make it into an SHTML file?

Now, my book said that there's a problem with telling Apache to look for HTML files also for SSI. I think I kinda understand why, but I'm not sure. I don't think I write to HTML files from forms. I mean a person enters some information in a form, and I store it in a MySQL table. Then I take that information and using Perl display it on the page. Is that what they mean? And if that's the case, couldn't they do the same thing to an SHTML file? I think I'm still a little confused with the whole thing. It's a lot more complicated then I thought it would be.

Oh yeah and one more thing, that I'm not sure you had answered in my original post. How do I get the output of a CGI script to be displayed on an HTML (or SHTML) page. This:

or this

I've seen it both ways, and I'm not sure which one to use. I thought #include was to just have the contents of the file displayed on the page.

Thanks for your help so far though. I really appreciate it.

>> because I didn't even have to do it

If you run Redhat then you do have to adjust their default mistakes. I have seen it many times here, Redhat by default set your cgi-bin to be ScriptAlias'ed and within <Directory "/physical/path/to/cgi-bin">, they set Options other than None.

>> But there's a problem with changing all the HTML files to SHTML files

Why bother to do that? Just change AddHandler server-parsed .shtml to AddHandler server-parsed .html .htm or preferably remove .htm if you don't use .htm extension at all.

>> it automatically goes to index.html

Why reveal your file name and extension when you can simply set the DirectoryIndex to index.html?

>> I includes something like <script src="logged.pl">

This is Perl forum and off-topic here. Anyway, instead of doing that in your *.html file, why don't you make index.pl and do all the tasks within one script or require your logged.pl into index.pl like so:

require "/path/to/logged.pl";

if you really don't want to rely anything on the client side (including any <Script> tag in your .html files.

>> telling Apache to look for HTML files also for SSI

If most or all of your html pages use SSI, then just use AddHandler server-parsed .html and forget about performance.

>> I thought #include was to just have the contents of the file displayed on the page

When your included file is a CGI script, the CGI will be executed and output will be displayed.

I change .shtml to .html in the AddHandler and SSI now works on my index.html page, but there's still a problem. It won't work on my Perl pages that display HTML pages. I figure that since I'm printing out an HTML header on the Perl page, that it'll be considered an HTML page, but I guess it just goes by the extension of the file, which is .pl. I tried adding .pl to the AddHandler, but that just made the .pl file displayed as text for some reason. Perl files that display HTML are mainly where the SSI are going to occur. I included a Perl file that displays the footer on the index.html page, but when I added to a perl file it didn't work.

Please help!

P.S. - The reason I had gone off topic with the Perl stuff is because I initially had posted this in the Perl forum and I didn't realize that it got moved to the Apache forum.

>> It won't work on my Perl pages that display HTML pages

Not sure exactly what you mean. Anyway, how many SSI tag do you have on that page? Try using <!--#exec cmd="/full/server/path/no/symlink/to/that/script.pl"-->

>> I tried adding .pl to the AddHandler

Don't even do that.

>> I didn't realize that it got moved to the Apache forum

I'd say it's in the grey area but it actually fits better in Perl forum.

Well here's what the part looks like that calls the SSI in the Perl script.

I thought the problem might be because # is used for comments, but it doesn't make a difference if I escape it or not. Plus, if I just put # sign as text, it dispalys fine. Here's what the end of the source code looks like when I do "View Source" on the page it makes:

Now do you understand what I'm talking about?

You can't output SSI directives via CGI and expect apache to parse them. That's your problem here. Apache passes CGI output directly to the user.

Apache doesn't look for SSI directives in every bit of text it outputs, only in text files that come from the file system.

You CAN embed exec SSI directives that call CGI scripts into static, apache-parsed files and have them work. I use this in several apps to stitch together pages in a rudimentary templatting system. It works OK, though you're better to go with a full-fledged templatting system like HTML::Template.

Okay, thanks for the clarification. I think I'll stick with using JavaScript now and I'll look into HTML::Template later on when I have time.