Having issues setting up ActivePerl 5.32 on IIS10 (Windows Server 2019)


I’m trying to setup my web site on a Windows Server 2019 machine using IIS10. The website is based on Perl files. I’ve installed a private ActiveState Perl project based off of ActivePerl 5.32.
I’ve configured the web server to invoke the Perl.exe file whenever any *.pl files are requested from the client’s browser using the IIS’s Handler Mappings configuration.

However, when I try executing the perlPerl file, I keep on getting the following error from my browser:

HTTP Error 502.2 - Bad Gateway
The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are “”.

Most likely causes:
The CGI process was shut down or terminated unexpectedly before it finished processing the request.
The CGI process has a flaw and does not return a complete set of HTTP headers.

Things you can try:
Check the event logs on the system to see whether the CGI process is shutting down unexpectedly.
Troubleshoot the CGI application to determine why it is not sending a complete set of HTTP headers.

Detailed Error Information:
Module CgiModule
Notification ExecuteRequestHandler
Handler StaticFile
Error Code 0xc0000142

The handler for the .pl file points to the Perl.exe file that was installed to location on my C:\ drive when I installed the ActiveState Perl project previously. There was a Perl.exe file and a Perl5.32.1.exe file in the same directory. I wasn’t sure which one to point to so I just used the Perl.exe file.

I’m pretty sure the configuration is not right somewhere and that’s why it’s not working. I wanted to make sure that I can use the ActiveState project as the target of the IIS handler mappings for the .pl file.

Any help is appreciated.

Windows 10 isn’t a good server, and that is entirely intentional. To get the parameter tunings that anything more than a proof-of-concept server will need, you’ll need one of the Windows Server 2019 editions intended to support webservers. It looks like you’ve already figured out that you need to add the IIS toolkit extensions that support legacy engines like the Classic ASP that CGI based sites must have, and that will be the case on a Server version as well.

Is for troubleshooting with IIS 7, but the general principles should be more or less the same.

If you can get those logs, it should show a CGI_LAUNCH event. Confirm there that the perl is configured to be started.

If all is as expected there, the empty headers being returned could mean that IIS is unable to start Perl or can’t run CGI from it. IIS is a service and unless you configure it differently, will be started by the (SYSTEM) userID that Windows uses to manage most services. By design in newer versions of Windows, the system user has very restricted access to what is on the disk. If Perl is not in a location which can be seen and executed by the system user, IIS will not be able to run Perl.

When 5.32 is installed a group of environment variables are set (and report at the end step of the deploy step). These may have only been set for your user ID. For others to run Perl, they need to be set globally. Another way (not great but possibly useful for testing) is to run the IIS process as a different user, such as yourself, to see if changing the environment will solve the startup problem.

You may also be lacking the CGI module. Old Perls defined that the CGI module was an inseparable part of Perl, so it would always be there, but our sample 5.32 projects are just as likely to not include it. If CGI is missing from your configuration, you’ll need to rebuild with CGI included, then remove and redeploy your current Perl instance.

A few years ago, CGI was removed from the core in order to encourage users to select better modern alternatives, like Plack, Catalyst, or Dancer web frameworks. Unfortunately for Windows Servers, all of modern Perl Frameworks expect to be served on webservers that are not IIS. You’ll find that hosting a Perl application on Linux offers many more choices, and if you are committed to using Perl, swapping out your server is likely inevitable.