Link to home
Start Free TrialLog in
Avatar of dbunder
dbunder

asked on

CGI.pm > 2.98 sends malformed headers

Setup:
FreeBSD 5.1
Apache 1.3.29 + PHP 4.3.4 + mod_perl 1.29
perl 5.8.2 from ports
scripts in question running under mod_cgi, not mod_perl

Script (for simplicities sake):
#!/usr/bin/perl -w
use CGI::Carp qw(fatalsToBrowser);
die "i'm dead!";

When I run a script (like the one above, or anything using CGI::Carp) under mod_cgi using the CGI.pm 2.99 or 3.0 package, I get the following an internal server error and a the following line appears in the error log:

[Tue Nov 11 20:49:30 2003] [error] [client 69.3.236.134] malformed header from script. Bad header=<pre>my error: /path/to/script/test.cgi

If I downgrade to CGI.pm 2.98 or below, I do not get these errors and everything works flawlessly.  I've posted to a couple of perl lists and nobody can figure it out.  I've tried stripping down to a basic httpd.conf, removing all the mod_perl and php directives, but I still get the same error.  Every other function of CGI.pm 3.0 works, it's just the CGI::Carp stuff that errors.

Any ideas?  If you have any questions about my setup and whatnot just ask. Thanks!

-j
Avatar of _nn_
_nn_

It looks like a known issue : http://www.mail-archive.com/beginners-cgi@perl.org/msg08913.html
I suggest reading the whole thread. I found http://www.mail-archive.com/beginners-cgi@perl.org/msg08928.html specially interesting, but all messages are apparently valuable.

As for the origin of the problem, I suspect that this change is responsible :

<quote>
CHANGE LOG
(...)
1.26 Replaced CORE::GLOBAL::die with the evil $SIG{__DIE__} because the former isn't working in some people's hands. There is no such thing as reliable exception handling in Perl.
</quote>
Avatar of dbunder

ASKER

I noticed this in the changelog and changed it back to CORE::GLOBAL::die and still got the same error.
:/ ... well then, it's probably more subtle and beyond my current investigation abilities. I'll add that I globally agree with what was said in the mentioned thread, e.g. change the way fatal errors are dealt with (did you try the set_message "hook" ?), before wishing you good luck. Hopefully, a Perl expert (I'm not) will be able to help you.
What happens when you run this at the console?
-LTG
Avatar of dbunder

ASKER

CGI.pm 2.98:
Content-type: text/html

<h1>Software error:</h1>
<pre>i'm dead! at t.pl line 3.</pre>
<p>
For help, please send mail to this site's webmaster, giving this error message
and the time and date of the error.

</p>
[Wed Nov 12 13:44:09 2003] t.pl: i'm dead! at t.pl line 3.

CGI.pm 2.99 and 3.0:
<h1>Software error:</h1>
<pre>i'm dead! at t.pl line 3.</pre>
<p>
For help, please send mail to this site's webmaster, giving this error message
and the time and date of the error.

</p>
[Wed Nov 12 13:42:27 2003] t.pl: i'm dead! at t.pl line 3.
Avatar of dbunder

ASKER

a little bit more info.

i diffed 2.98 and 3.00 and noticed that 3.00 has some new checks for mod_perl.  when these checks test positive for mod_perl, CGI::Carp doesn't send a header, since mod_perl should do that for you automatically.

the way it checks to see if it is running under mod_perl is it checks if $ENV{MOD_PERL} exists.  i ran a script under the webserver to check for $ENV{MOD_PERL} and it came up negative.  so it wasn't that.  but just to be safe, i edited Carp.pm so it always tests negative for mod_perl no matter what the conditions.  still got the same error.  

even more baffled now.
Ignore this V.V. points, but if you hand roll your headers in 2.99 and 3.0, you should remove the malformed headers problem

The notion of a CGI module is that you shouldn't have to do this, but in 2.99 and 3.0, it looks like they've got a lot stricter, and you haven't made a call to [b]start_html()[/b] which would have generated the header
LTG
Avatar of dbunder

ASKER

CGI::Carp's die() subroutine (when fatalsToBrowser is imported) explicitly sends a well-formed header.  But for some reason the newer versions of CGI.pm don't send it.  Still confused.  But 2.98 works fine.
I agree that the question has not been answered, but I'd like to see this question PAQed.

The behavior of 2.99 and 3.0 revs of CGI looks wrong, since the whole point of fatalsToBrowser is to arrange for a sensible HTML-format document to be sent to the browser in the event that an error occurs. It has to do this even if no code in the script manages to get executed. Having this record of the problem may speed resolution of similar problems in the future.
Avatar of dbunder

ASKER

Good idea, jmcg!  I agree.
Concurred
ASKER CERTIFIED SOLUTION
Avatar of Lunchy
Lunchy
Flag of Canada image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial