Perl CGI using HTML::Template

Question

I would like to make use of the HTML::Template module but somehow I can't set it up to work properly. Here is a very simple representative code I'm testing on:

use strict;
use warnings;

use CGI;
use HTML::Template;

my $test = new CGI;
my $tmpl = HTML::Template->new(filename => 'TemplateSimple.html');

$tmpl->param(
    title => 'Test',
    body  => '<p>This is a test</p>',
);

my $out = $test->header(
    -type    => 'text/html',
    -charset => 'utf-8'
);


print $out;
print $tmpl->output;

When calling the page I always end up with the browser displaying the server error message:

502 - Web server received an invalid response while acting as a gateway or proxy server.

TemplateSimple.html

<!DOCTYPE html>
<html lang="de">
    <head>
        <meta charset="utf-8">
        <title><TMPL_VAR NAME=title></title>
        <link rel="SHORTCUT" ICON href="favicon.ico" />
    </head>

    <body>
        <TMPL_VAR NAME=body>
    </body>
</html>

I have to use CGI, because I want to process user input on the web page, but I would like to define the basic HTML structure in a template where I can insert code segments as necessary.

Edit

I think that it could have something to do with different configs between the local Perl (run from eclipse, which does run fine) and the Perl CGI config. Does anybody know of such a case?

Edit

After setting up a Perl CGI configuration in Eclipse, the script runs as expected from the local host. However, the problem when calling the page from an external source persists. So like DaveCross suggested, the bug lies in the web server configuration rather than the Perl script.

What gets written to the web server error log? What do you see if you compile the program from the command line (with `perl -c`)? Is HTML::Template installed? It's 2017, why are so many people still writing CGI programs? :-( — Dave Cross, Mar 22 '17 at 09:41
Hehe, sorry the company I work for still uses it...I would prefer something more modern too. I don't know where the server error log is, but when I run the perl script within eclipse, i get the following console output: `Content-Type: text/html; charset=utf-8 HTML::Template=HASH(0x5a2f74)`. When i use `print $tmpl->output` the console output looks as desired, but the in the browser I still get the error message. — N. Maks, Mar 22 '17 at 09:49
@DaveCross because no-one is writing a proper full-featured guide on how to deploy PSGI stuff. I hear you have a fancy blog... want some TUITs? :) — simbabque, Mar 22 '17 at 09:50
@N.Maks - You code works (well, modulo needing the `->output` call, but you've already spotted that). So the problem is in the way your program is interacting with your web server. And you've told us nothing about how that is configured. Saying "I don't know where the server error log is" isn't very helpful. You can't do serious web development without access to the error log. I'm confident there will be useful clues in there. — Dave Cross, Mar 22 '17 at 09:55
alright, thank you for the hint. It's a starting point to know that it isn't the code which causes the trouble. I will try my luck with the sever configuration and see if I can find something which helps. — N. Maks, Mar 22 '17 at 09:59
@N.Maks If you work it out, please come back and write an answer - so it helps other people with the same problem. — Dave Cross, Mar 22 '17 at 11:18
Ok. So looking at your edits to the question, I see we're all agreed that the problem is in the interface between the web server and your CGI program. So now we might be more help if you gave us more information about how that is set up. What platform are you using? What web server is it? Do other CGI programs work in this environment. And, at the risk of getting repetitive, have you found the error log yet? What is in it? — Dave Cross, Mar 22 '17 at 14:37
@DaveCross: I agree wholeheartedly with **simbabque**. There is little to no explanation of what PSGI *actually is*. What I do know is that it's Perl-specific, whereas the *Common Gateway Interface* is, well, common to many languages, and my experience isn't broad enough to know whether other languages have done their own thing in a similar way. CGI is well-known, "common", and has heritage. PSGI is virtually undocumented and hides behind Perl "this will do all you need" modules, and relies on the "this is the new thing" hype to get started. Can you suggest why PSGI is "better"? — Borodin, May 29 '18 at 08:32
@Dave: The Wikipedia page for PSGI is a ghost town. Likewise Plack and Plackup, where I read that both Ruby and Python have their own variants. This seems like a huge backward step to me. Perhaps you should elaborate? — Borodin, May 29 '18 at 08:34
@Borodin: I agree that we haven't been very good at explaining exactly why PSGI is a better solution than CGI. I've started a couple of projects to address that, but they stalled before getting anywhere. Perhaps I'll find time to get back to one of those. But I'll summarise the main three advantages in comments below. — Dave Cross, May 29 '18 at 09:11
1/ PSGI uncouples your code from its deployment environment. CGI is an inherently slow technology. To improve performance, you'll need to use mod_perl or FCGI. And both of those will involve major changes to your code. If you write a PSGI application, then you can deploy it as a CGI program, under mod_perl or FCGI or even as a standalone service behind a proxy. And you won't need to change the code at all. — Dave Cross, May 29 '18 at 09:15
2/ A PSGI app has a simple interface. It's a subroutine with defined inputs and defined outputs. This simplicity makes it simple to write powerful debugging and testing tools. — Dave Cross, May 29 '18 at 09:16
3/ The simple interface also opens the door to a powerful ecosystem of middleware. For example, you can short-circuit requests for static files and send them directly to the filesystem rather than running most of your application. I know you can do that wilth Apache or nginx confuguration, but I find it helpful to have those rules inside the application codebase. — Dave Cross, May 29 '18 at 09:19

score 1 · Accepted Answer · edited May 29 '18 at 08:14

When initializing the HTML::Template object in the Perl script

my $tmpl = HTML::Template->new(filename => 'TemplateSimple.html');

I had to specify the full path instead of just the filename, so

my $tmpl = HTML::Template->new(filename => 'C:/inetpub/wwwroot/Project/TemplateSimple.html');

This solved my problem.

To whom it may interest, the webservice was set up with IIS 7, in the very basic and standard way.

Perl CGI using HTML::Template

TemplateSimple.html

Edit

Edit

1 Answers1