in reply to SSI Includes inside .htm Perl Template Files

Update Just read your question again, if the original bit below isn't what you meant, do you mean that you have a static site (that is auto generated by Perl) but your SSI isn't working anymore?

If this is the case, you need to check the file extension as most servers are configured for files ending with .shtml and not html or htm. I would experiment.

Otherwise, read below.

Original

SSI is not specific to Perl but is run by the web server itself. As such, someone has configured your server to inspect ordinary web files (html ones) to look for SSI commands (or directives) and process them.

The reason why it doesn't work in your Perl program is because the web server passes the responsibility for generating content to your program and just passes the output back to the browser. It doesn't do any post processing.

You can get around this by using one of the SSI modules available from CPAN. Here you would first generate your content using HTML::Template and then you would post process it with the SSI module.

You could also, if you have it available, use mod perl and implement some form of filter chain, where SSI happens at the end.

However, I would have thought that using HTML::Template would have given you what you needed. Why not write in what you are trying to do? We could give you some design pointers.
  • Comment on Re: SSI Includes inside .htm Perl Template Files

Replies are listed 'Best First'.
Re: Re: SSI Includes inside .htm Perl Template Files
by spiderbo (Sexton) on Mar 25, 2003 at 09:50 UTC

    "Why not write in what you are trying to do? We could give you some design pointers. " ... well it is rather complicated, but I will give it a go.

    I am working on a Linux webserver used by two groups, group A and group B. They are two separate groups and share no common code up until now. I work for group A, however have complete knowledge of group B's site. Group A has access to the entire Linux server, group B only has limited access (folders within their virtual server).

    Group A has some code it wishes to include in group B's web pages (it displays a data-driven calendar), the use of Server Side Includes has achieved this.

    The code (written in PERL by group A) is complex (generates dynamic html and javascript files) and secure, and group B should not be able to see or edit the PERL source code.

    The server side includes worked fine on groub B's standard .htm files. However, when I tried inserting the same include line on files which had <TMPL> tags (obviously variables generated with the use of HTML::Template by group B's cgi scripts), it failed.

    Does that give you a better idea of what I am trying to do? Sorry if it is a little confusing.

    I am tring to limit the amount of code mixing between Group A and Group B, but it seems maintaining the simplicity of server side includes when dealing with HTML::Template will be difficult.

[reply]
      If I understand this correctly, you have Perl programs in your area which produce HTML output. This HTML output is to be included into the pages held by the other group.

      However, you don't want the other group to see the source. Additionally, group B has both HTML pages and CGI scripts. The SSI works find in the HTML pages but the CGI programs use HTML::Template and the SSI is not coming out.

      If that is the case, you need to refer to my note above about the server not post processing CGI output. You need to re-write the CGI programs to implement post processing via SSI or you need to use mod perl and implement a filter chain and have SSI parsed at the end. This, of course, assumes you are using Apache.

      If you don't want to touch their apps then mod perl is the way to go but it will add more overhead on you as well as increase the load on the server (increased process size etc).

      If both group A and group B work for the same company why not produce a simple in-house API that group B must use on their scripts output? Ok this is a little bit of code mixing but you are doing it in a structured and formalised way (or will do if you get it right). Just a thought.

      HTH

      SP
[reply]

        Many thanks, you have got it absolutely right, additionally, yes it is an apache server.

        Group A and group B are two very separate companies and want to remain independant of one-another. Group B has subcontracted group A for its web server and some software development, group A's software (which is web-based), sits on the shared web server in an area which group B does not have access to.

        I am not very keen on the Mod Perl idea, however, am not entirely sure what you mean by "You need to re-write the CGI programs to implement post processing via SSI ". I am teribly sorry to sound thick and take up more of your time, however it is very much apreciated.

[reply]

In Section Seekers of Perl Wisdom