Instead, why not just open and print the file to the web browser? I like something like this:

{
    local *INPUT;
    open (INPUT, "file.ext") or warn "Cannot open file: $!" && return;
    print while (<INPUT>);
    close INPUT;
}
[download]

{
    local *INPUT;
    if (open(INPUT, "file.ext")) {
        print while (<INPUT>);
        close INPUT;
    } 
# for diagnostic purposes, uncomment these lines
#     else {
#        print "Couldn't open file: $!";
#    }
}
[download]

If you are using mod_perl you can try Apache::Filter+Apache::SSI or Apache::SSIChain (based on Apache::OutputChain and Apache::SSI). The second variant permits you to filter almost all - plain HTML, output from other mod_perl scripts or from usual CGI scripts written in any language, and so on.

Both variants are fully mod_include complaint and have two additional powerful features (well, Apache::SSI have them):

• calling perl subs and including results
• really good if..elif..else construct)

I wrote a module I call 'Text::SSITemplate' to get around the fact that mod_include (or whatever you use to parse your SSIs) never sees the output of a CGI program. This is mostly an implementation of Apache's mod_include without 'exec':

SSITemplates.tar.gz

The tarball includes pod documentation, an example cgi, example templates, and the SSITemplate library. I'd be really interested to hear what folks think of this (and whether I should put it on the CPAN). This does not require mod_perl, but if you run mod_perl there is an Apache::SSI on the CPAN that you may want to look at.

Most of the better templating systems allow you to do this fairly easily. With Template::Toolkit, it is as simple as putting

[% INCLUDE filename %]
[download]

SSIs don't work from within Perl scripts (least I've never known them too). They only work within static documents, because the web server, when it gets a request for a Perl script, hands off control to perl, which is then expected to basically just write its output back to the client.

The server doesn't actually parse the HTML written by the Perl script (as compared to when you use SSIs in a server-parsed HTML file, when the server parses the file to find any SSIs), so your SSIs won't get expanded if you try to include them in the HTML outputted by a Perl script.

mod_include.c cannot catch the output of a CGI so you have to process SSI directives from inside the script. try with CGI::SSI (available on CPAN)

Yes you can actually. You can install mod_filter and have the perl scripts run through mod_include. Take a look at http://tangent.org/mod_filter/

Instead of outputting to the browser, couldn't the CGI write a .shtml file, and send an HTTP "Location:" header to the browser that redirects to the outputted file? The downside is that you'ld have to have it write unique files each time it's accessed to prevent conflicts if one person hits the script before another has finished downloading the output (Maybe a filename based on the time?). You'ld also have to have some way of flushing out the .shtml files every so often. (Maybe this isn't such a great idea.)

why do all that just open the html document you would have normally put in the include tag and print it out... ie.

open(B, "any.html"); 
while(<B>){
$line = $_; 
print $line;
}
[download]