Bloodnok has asked for the wisdom of the Perl Monks concerning the following question:

Hi all ,

I'm attempting to run perl CGI scripts on a Win2K3 machine using IIS 6.0 & Strawberry-perl. Having now struggled thro' configuring IIS appropriately, attempting to browse my script results in a 'CGI Timeout ...' error. In an attempt to debug it, I've replaced my script with the code : 

map { print "$_ => $ENV{$_}\n" } keys(%ENV);

[download]
... the problem persists (when run from CLI, this takes an almost infintesimally small time to run).

I've googled for 'CGI Timeout' & IIS - the majority of hits concern timeouts when loading pages/CGI scripts containing/generating a large amount of forms - as you'll see from the above, this simply isn't the case.

Have any of you good monks any suggestions as to my next step ... short of using LAMP of course :-))

At last, a user level that best describes my experience :-))

Replies are listed 'Best First'.
Re: IIS & perl - are they compatible ?
by moritz (Cardinal) on Jan 31, 2008 at 12:18 UTC
    The first step is to print a header: 
    use CGI qw/:standard/;
print header();

map { print "$_ => $ENV{$_}\n" } keys(%ENV);

    [download]

    If that still doesn't work, log in your server's log files (on apache that's error.log, I don't know how IIS calls the log files).

[reply]
[d/l]
      TFT ,

      I didn't bother with any useage - just in case that was causing the problem.

      I have copied the .pl script to .htm (in the same location) and browsing that gives what would expect i.e. 'map { print "$_ => $ENV{$_}\n" } keys(%ENV);' as plain text.

      On inspection of the somewhat terse log, it would appear that an HTTP 502 (Bad gateway) error is being generated.

      At last, a user level that best describes my experience :-))
[reply]
Re: IIS & perl - are they compatible ?
by digger (Friar) on Jan 31, 2008 at 16:16 UTC

    The quick answer to your question is yes, IIS and perl work fine together.

    In this case, moritz is correct. You are not sending the correct header, so you are getting an error from IIS. Admittedly, the message from IIS wasn't extremely helpful, but the suggestion given was. Print the header first, using either the CGI module as indicated above or just adding print "Content-type: text/html\n\n" to the top of your script.

[reply]
[d/l]
      my quick replay is: yes they are compatible BUT they does not work well together:

      1-you have to use the minor-useful perl.dll
      2-you get into a lot of blind error filled dungeon..
      3-you have many account problem
      4-if you wish to use some more complex then a primitive club it will be a pain to debug
[reply]

        I agree with all of your points, but unfortunately they don't apply just to perl. The blind dungeons and difficult to manage permissions issues are endemic to C# as well. In reality, it is the model imposed by IIS that causes most of these problems.

        That wouldn't even be so bad if it weren't for the lack of accessible, correct documentation. The LAMP world has MS beat by a mile when it comes to quality support tools.

[reply]
      TFT Digger ,

      Done as suggested and included the printing of a header ... still doesn't work, but the symptoms have now changed (no surprises there then, TFT M$). The error is now a 404 error - the so-called error log indicates an alternating sub-status of 00 and 02 !?!

      • The file is most definitely present (at the browsed location),
      • A web service extension is enabled allowing access to the perl binary and ...
      • that self-same binary is configured as being required to run files having a '.pl. extension and moreover, ...
      • The indicated perl binary has identical permissions to a DLL that can be run from the same location.

      P.S. I have downloaded the IIS 6 toolkit - all the tools contained therein appear to do is to present the 404 error web page in a number of different formats. What an idiot for thinking it might be useful and give me a clue (no matter how small) as to WTF is going on !!

      At last, a user level that best describes my experience :-))
[reply]
        How about the permissions on the .pl script?
[reply]
Re: IIS & perl - are they compatible ?
by oyse (Monk) on Feb 01, 2008 at 11:12 UTC

    I can't say I have had that much problem with using Perl on IIS 5.1 using pure CGI and perl.exe.

    The only problem I can think of is that timeout configuration does not work properly and have to by set under Web Sites->Properties instead for the specific sites.

    As far as I know, no really good mod_perl equivalent is available, but FastCGI should work. FastCGI is now officially supported on IIS, but i haven't had a chance to try that yet. http://www.iis.net/fastcgi

    What problems are you others referring to? Is there something I have missed that I should be aware of? Security/stability issues for instance?

[reply]
Re: IIS & perl - are they compatible ?
by menolly (Hermit) on Feb 01, 2008 at 18:15 UTC

    The original issue has been addressed, but for the information of future searchers:

    I spent two years doing maintenance and development for a major ecommerce site which was built in Perl under IIS. That was 6-8 years ago (2000-2002), using NT and ActiveState, so I can't speak for modern configurations, but it worked fine then.

[reply]

      Just a quick example from a current project. It isn't perl specific, but as I said above, it is usually IIS.

      I developed a web app using Visual Studio on Win XP/IIS5. It worked great, and passed initial QA for alpha testing. When I migrated it to the test server running Server 2003/IIS6, it failed with an error message that looked like an AD issue. After much digging and debugging, I found out that the default permissions on one of the IIS metabase keys changed from IIS5 to IIS6, so I couldn't read a value that I needed. I had to actually change the metabase key permissions when the software was installed. So much for an xcopy deployment.

      Just one of many interesting encounters I have had with IIS in the last year in this position.

[reply]

Back to Seekers of Perl Wisdom