End of script output before headers

rtwingfield

rtwingfield

I can finally execute a "Hello world" Perl script from a command line (have encountered numerous problems with upgrade to perl5-5.24.0), but when called from a Firefox browser session, the following errors are reported:

Code: 
[Thu Jun 02 04:47:00.927168 2016] [cgi:error] [pid 73280] [client 9.9.9.9:43404] AH01215: (2)No such file or directory: exec of '/www/vhosts/foobar.net/cgi-bin/perl/hello.pl' failed: /www/vhosts/foobar.net/cgi-bin/perl/hello.pl, referer: http://foobar.net/
[Thu Jun 02 04:47:00.942718 2016] [cgi:error] [pid 73280] [client 9.9.9.9:43404] End of script output before headers: hello.pl, referer: http://foobar.net/

This thread (10 months old and marked solved) described an obscure solution that doesn't work in my case: https://forums.freebsd.org/threads/52478/#post-294495. You can google around and find other similar scenarios, one even suggesting a bug in the Apache2.4.+ system.

I've had to reinstall the Apache2.4.20 instance (previous working version destroyed by Synth . . .?) and have changed nothing significant in the httpd.conf file. Regardless, it was working before, but now fails.

In the httpd.conf file, has something changed in the system that would be effected by the following directives?
Code: 
LoadModule mpm_prefork_module libexec/apache24/mod_mpm_prefork.so

<IfModule mpm_prefork_module>
   LoadModule cgi_module libexec/apache24/mod_cgi.so
</IfModule>
 
SirDice said:
Can you post your Perl script?
Click to expand...
Yeah, it's this complex piece:

Code: 
#!/usr/bin/perl -wT

#use strict;
use warnings;
use CGI qw(:standard);
use CGI::Carp qw(fatalsToBrowser);

print header;

print start_html("Hello World");
print "<h1>Hello from Perl!</h1>\n";
print end_html;

Here's the result of a CL execution:

# perl -wT hello.pl
Code: 
Content-Type: text/html; charset=ISO-8859-1

<!DOCTYPE html
  PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US">
<head>
<title>Hello World</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<h1>Hello from Perl!</h1>

</body>
</html>




*** EDIT ***

. . .and just for fun, I've dumb'ed it down to this essential code:

Code: 
#!/usr/bin/perl -wT
print "Hello from Perl!\n";

. . .same error problem.


*** EDIT ***

. . .and for even more fun :p , I had sort of an epiphany . . .let's try to call something bogus that doesn't exist, e.g., bogus.pl and the error returned is
Code: 
[Thu Jun 02 17:11:45.174703 2016] [cgi:error] [pid 77155] [client 192.168.1.1:56440] AH02811: script not found or unable to stat: /www/vhosts/9.9.9.9.net/cgi-bin/perl/bogus.pl, referer: http://9.9.9.9.net/
a different error message . . .so apparently, the Apache system is finding the valid target . . .but refusing to render it.
 
rtwingfield said:
. . .and just for fun, I've dumb'ed it down to this essential code:
Code: 
#!/usr/bin/perl -wT
print "Hello from Perl!\n";

. . .same error problem.
Click to expand...
Yes, with this bit of code I actually expect the error as it's missing the Content-Type header. This shouldn't produce the error:
Code: 
#!/usr/local/bin/perl
print "Content-Type: text/plain\n\n";
print "Hello World!";

Also make sure the script is marked as executable.
 
SirDice said:
Yes, with this bit of code I actually expect the error as it's missing the Content-Type header. This shouldn't produce the error:
Code: 
#!/usr/local/bin/perl
print "Content-Type: text/plain\n\n";
print "Hello World!";
Click to expand...
. . .exactly, it was an attempt to force some other error msg., but it didn't.

You know, the solution just popped out of your post like a bolt out of the blue!
Code: 
#!/usr/local/bin/perl
. . .there is no /usr/bin/perl. All of my perl scripts are coded with
Code: 
#!/usr/bin/perl
Most are over six years old. (A period when I was actively writing a lot of Perl.) As I've mentioned, I've encountered a lot of difficulty regarding the upgrade to /usr/ports/lang/perl5.24; regardless, here in Little Rock, AR USA at ~3:30 AM (10:30 AM Amsterdam), I read your post and boom! . . .there it was. How silly of me . . .just couldn't see the forest for the trees.

The scripts will execute from the CL, # perl hello.pl but if invoked from a browser session, the code
Code: 
#!/usr/bin/perl
isn't pointed to
Code: 
#!/usr/local/bin/perl
In fact, the script will execute from the CL without the #!shebang code.

In defense of my oversight, the error messages are extremely ambiguous and subject to a lot of "dreaded" criticism out in Google-world.
Code: 
AH01215: (2)No such file or directory: exec of '/www/vhosts/foobar.net/cgi-bin/perl/hello.pl' failed: /www/vhosts/foobar.net/cgi-bin/perl/hello.pl
End of script output before headers: hello.pl
The "programmers" that wrote this stuff know the what-when-where-why of the problem. Is it too much to ask that an extra error-message be coded into the system? . . .a message that actually means something. This is just too Microsoft-esk. o_O

But anyway, thanks for your attention to my problem. It was a ricochet hit, but very helpful.
 
Aha! Yeah, that has bitten me more than once before too. The error message is indeed extremely confusing but it has to do with the way scripts are executed.
 
You're reading too much into it, it's an older than sin feature of unix shell scripts that use the shebang technique and it vastly predates anything the Microsoft produced. Surprisingly it's entirely dependent on which shell you're using, some shells can work around the problem and report something more meaningful. This is with shells/zsh and a shell script that tries to use non-existent /bin/bash:

Code: 
freebsd10 ~ % ./shebang.sh
zsh: ./shebang.sh: bad interpreter: /bin/bash: no such file or directory
freebsd10 ~ %

The default shell sh(1) on the other hand follows as closely as possible what the historical bourne shells did in the same situation.
 
Sure, but in this case that's probably going to cause issues as the script is started as CGI from Apache. And as far as I know Apache's path doesn't include /usr/local/bin/. But maybe this has been rectified since I last used CGI scripts.
 
SirDice said:
Sure, but in this case that's probably going to cause issues as the script is started as CGI from Apache. And as far as I know Apache's path doesn't include /usr/local/bin/. But maybe this has been rectified since I last used CGI scripts.
Click to expand...

If memory serves, it can actually be even more troublesome than simply missing from Apache's path. E.g. if Apache was last started from the command line with something like /usr/local/etc/rc.d/apache24 start, it may well have /usr/local/bin in its path, allowing your scripts to work perfectly until the next time the system is rebooted.

You should be able to ensure that appropriate /usr/local stuff, and any other necessary environment is set for Apache by either editing /usr/local/sbin/envvars or adding a suitable script to /usr/local/etc/apache24/envvars.d. The latter of those two should be the safer choice, as the former might get clobbered by a port/pkg update.

Personally, I recommend just using #!/usr/local/bin/perl, which also saves an exec(2) and a bunch of path enumeration. Admittedly, that saving isn't a compelling argument when balanced against the cost of starting a new Perl instance, but it is still a saving. The env trick is handy if you need a script to work across a broad range of systems without modification, but really doesn't add any value in the case of a CGI script which is only expected to execute on the local system.

Whatever solution is used, it needs to be verified after a full system reboot, due to the quirk of daemons inheriting interactive user environment when started from an interactive command line.
 
You must log in or register to reply here.
Back
Top