1

Okay, this is a weird one.

All of our servers are using ActivePerl 5.8.8 and windows server 2003.

During some development, we ran into an issue where the script we were working on started throwing back CGI errors. No amount of printing headers would work, just constant CGI errors. The issue was relegated to one development server.

After a bunch of digging, I found that the issue is related to warnings. When perl throws certain warnings the page comes back from IIS with a bad CGI header and nothing in the body. Specifically the warning about concatenating an un-initialized string.

Here's the test script I'm using.

use strict;


Main();

sub Main {
  my $Web = new CGI;
    my $SQL = VIN::SQL->new('INDIGO');
  print $Web->header();
  print "Testing!";
  print "/r/n/r/n/";
  my ($Body, $Title) = ('', '');
    my $Page;
    eval{
        $Page = "";
        $Page  = $Web->param('Page');
        print "Page " . $Page;

    };
}

Adding a no warning statement will mean it runs. Adding the Page param will also mean it runs.

Any idea on what might be causing it? I would like to understand why before just adding a "no warning" statement and moving on, as if this happens in our live enviroment, I'd prefer not to add a no warnings; statement to every perl script in the system.

Thank you so much for all your help.

Char George
  • 104
  • 5

2 Answers2

2

$Page should not be undef, so || "" makes sure that empty string is assigned instead.

sub Main {
  my $Web = new CGI;
  my $SQL = VIN::SQL->new('INDIGO');
  print $Web->header();
  print "Testing!";
  print "/r/n/r/n/";
  my ($Body, $Title) = ('', '');

  my $Page = $Web->param('Page') || "";
  print "Page ". $Page;
}
mpapec
  • 50,217
  • 8
  • 67
  • 127
  • Right, I understand that. If I do that the code works okay. unfortunately, this warning is common and it's been running fine like this for ~8 years. Now something in our system changed, causing perl to return bad headers whenever this happens. We have a number of scripts that would need to be updated should this issue occur outside the dev environment. There's no Debug information either, nothing shows wrong in the system log or goes to stderror as far as we can see, so tracking down where it occures to fix each individual warning is kind of a nightmare. Any idea the cause of this? – Char George May 24 '13 at 14:07
  • I would look what was previous perl version on the server. – mpapec May 24 '13 at 14:20
  • All servers are 5.8.8 revision 222, and that hasn't changed. – Char George May 24 '13 at 15:45
1

Something is getting an error message that is heading to the server before print $Web->header(); is being invoked. This means the output to the server is something like:

Error on line 123: Cannot create foo
Content-Type: text/html; charset=ISO-8859-1

Testing

Which is a bad header.

An easy fix to the printing of the header to the earlier part of the code.

Swapping the lines:

  my $SQL = VIN::SQL->new('INDIGO');
  print $Web->header();

to

  print $Web->header();
  my $SQL = VIN::SQL->new('INDIGO');

Will likely fix the problem (of bad header) and instead print the error message that is being generated to the browser.

  • That one was my initial thought, but unless I wrap the header print in a BEGIN block the error seems to prepend the header before sending it out. Thanks for taking a look. – Char George May 24 '13 at 17:02
  • @CharGeorge Depending on how STDOUT and STDERR are configured (if STDERR goes to the browser), the buffering on STDOUT may cause a print to STDERR to show up before an earlier print to STDOUT. Moving the header to the BEGIN {} block would fix this. See also [Redirecting CGI error output from STDERR to a file (python AND perl)](http://stackoverflow.com/questions/1781436/) for some thoughts about this. –  May 24 '13 at 18:14