ewalstad
asked on
Apache, C++ CGI Script Error.
When I run a really simple script("firsttest") on my apache server, the page is displayed properly. However, when I try to run a complex script ("websim"), I get an "Internal Server Error." (all the scripts are written in C++)
I'm running apache under Caldera Linux 2.3
Both scripts have owner=root and group=root
The httpd.conf file has:
User nobody
Group nobody
In the server error_log, it says:
"Premature end of script headers"
Note that the script runs fine when I run it on the console.
Here's the html that calls the script:
<HTML>
<HEAD>
<TITLE>CGI Tester</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<META HTTP-EQUIV="Content-Langua
</HEAD>
<BODY>
<!-- -->
<P>This is the launch pad to test CGI programs</P>
<FORM NAME="frmTestCGI" ACTION="http://192.168.1.100/cgi-bin/firsttest" METHOD="POST">
<P>
<INPUT TYPE=SUBMIT NAME="btnFirstTest" VALUE="Call FirstTest">
</P>
</FORM>
<FORM NAME="frmTestWebSim" ACTION="http://192.168.1.100/cgi-bin/websim" METHOD="POST">
<P>
<INPUT TYPE=SUBMIT NAME="btnWebSim" VALUE="Call WebSim">
</P>
</FORM>
</BODY>
</HTML>
I need to get the websim script to run! Please help!
I'm running apache under Caldera Linux 2.3
Both scripts have owner=root and group=root
The httpd.conf file has:
User nobody
Group nobody
In the server error_log, it says:
"Premature end of script headers"
Note that the script runs fine when I run it on the console.
Here's the html that calls the script:
<HTML>
<HEAD>
<TITLE>CGI Tester</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<META HTTP-EQUIV="Content-Langua
</HEAD>
<BODY>
<!-- -->
<P>This is the launch pad to test CGI programs</P>
<FORM NAME="frmTestCGI" ACTION="http://192.168.1.100/cgi-bin/firsttest" METHOD="POST">
<P>
<INPUT TYPE=SUBMIT NAME="btnFirstTest" VALUE="Call FirstTest">
</P>
</FORM>
<FORM NAME="frmTestWebSim" ACTION="http://192.168.1.100/cgi-bin/websim" METHOD="POST">
<P>
<INPUT TYPE=SUBMIT NAME="btnWebSim" VALUE="Call WebSim">
</P>
</FORM>
</BODY>
</HTML>
I need to get the websim script to run! Please help!
well, what s the apache error_log file saying?
ASKER
edicom,
As I mentioned,
In the server error_log, it says:
"Premature end of script headers"
That's it. I have no idea what that means, though.
As I mentioned,
In the server error_log, it says:
"Premature end of script headers"
That's it. I have no idea what that means, though.
Well here I ll just quote apache FAQ:
2.What does it mean when my CGIs fail with "Premature end of script headers"?
It means just what it says: the server was expecting a complete set of HTTP headers (one or more followed by a
blank line), and didn't get them.
The most common cause of this problem is the script dying before sending the complete set of headers, or
possibly any at all, to the server. To see if this is the case, try running the script standalone from an interactive
session, rather than as a script under the server. If you get error messages, this is almost certainly the cause of
the "premature end of script headers" message. Even if the CGI runs fine from the command line, remember
that the environment and permissions may be different when running under the web server. The CGI can only
access resources allowed for the User and Group specified in your Apache configuration. In addition, the
environment will not be the same as the one provided on the command line, but it can be adjusted using the
directives provided by mod_env.
The second most common cause of this (aside from people not outputting the required headers at all) is a result
of an interaction with Perl's output buffering. To make Perl flush its buffers after each output statement, insert
the following statements around the print or write statements that send your HTTP headers:
{
local ($oldbar) = $|;
$cfh = select (STDOUT);
$| = 1;
#
# print your HTTP headers here
#
$| = $oldbar;
select ($cfh);
}
This is generally only necessary when you are calling external programs from your script that send output to
stdout, or if there will be a long delay between the time the headers are sent and the actual content starts being
emitted. To maximize performance, you should turn buffer-flushing back off (with $| = 0 or the equivalent)
after the statements that send the headers, as displayed above.
If your script isn't written in Perl, do the equivalent thing for whatever language you are using (e.g., for C, call
fflush() after writing the headers).
Another cause for the "premature end of script headers" message are the RLimitCPU and RLimitMEM
directives. You may get the message if the CGI script was killed due to a resource limit.
In addition, a configuration problem in suEXEC, mod_perl, or another third party module can often interfere
with the execution of your CGI and cause the "premature end of script headers" message.
2.What does it mean when my CGIs fail with "Premature end of script headers"?
It means just what it says: the server was expecting a complete set of HTTP headers (one or more followed by a
blank line), and didn't get them.
The most common cause of this problem is the script dying before sending the complete set of headers, or
possibly any at all, to the server. To see if this is the case, try running the script standalone from an interactive
session, rather than as a script under the server. If you get error messages, this is almost certainly the cause of
the "premature end of script headers" message. Even if the CGI runs fine from the command line, remember
that the environment and permissions may be different when running under the web server. The CGI can only
access resources allowed for the User and Group specified in your Apache configuration. In addition, the
environment will not be the same as the one provided on the command line, but it can be adjusted using the
directives provided by mod_env.
The second most common cause of this (aside from people not outputting the required headers at all) is a result
of an interaction with Perl's output buffering. To make Perl flush its buffers after each output statement, insert
the following statements around the print or write statements that send your HTTP headers:
{
local ($oldbar) = $|;
$cfh = select (STDOUT);
$| = 1;
#
# print your HTTP headers here
#
$| = $oldbar;
select ($cfh);
}
This is generally only necessary when you are calling external programs from your script that send output to
stdout, or if there will be a long delay between the time the headers are sent and the actual content starts being
emitted. To maximize performance, you should turn buffer-flushing back off (with $| = 0 or the equivalent)
after the statements that send the headers, as displayed above.
If your script isn't written in Perl, do the equivalent thing for whatever language you are using (e.g., for C, call
fflush() after writing the headers).
Another cause for the "premature end of script headers" message are the RLimitCPU and RLimitMEM
directives. You may get the message if the CGI script was killed due to a resource limit.
In addition, a configuration problem in suEXEC, mod_perl, or another third party module can often interfere
with the execution of your CGI and cause the "premature end of script headers" message.
Well here I ll just quote apache FAQ:
2.What does it mean when my CGIs fail with "Premature end of script headers"?
It means just what it says: the server was expecting a complete set of HTTP headers (one or more followed by a
blank line), and didn't get them.
The most common cause of this problem is the script dying before sending the complete set of headers, or
possibly any at all, to the server. To see if this is the case, try running the script standalone from an interactive
session, rather than as a script under the server. If you get error messages, this is almost certainly the cause of
the "premature end of script headers" message. Even if the CGI runs fine from the command line, remember
that the environment and permissions may be different when running under the web server. The CGI can only
access resources allowed for the User and Group specified in your Apache configuration. In addition, the
environment will not be the same as the one provided on the command line, but it can be adjusted using the
directives provided by mod_env.
The second most common cause of this (aside from people not outputting the required headers at all) is a result
of an interaction with Perl's output buffering. To make Perl flush its buffers after each output statement, insert
the following statements around the print or write statements that send your HTTP headers:
{
local ($oldbar) = $|;
$cfh = select (STDOUT);
$| = 1;
#
# print your HTTP headers here
#
$| = $oldbar;
select ($cfh);
}
This is generally only necessary when you are calling external programs from your script that send output to
stdout, or if there will be a long delay between the time the headers are sent and the actual content starts being
emitted. To maximize performance, you should turn buffer-flushing back off (with $| = 0 or the equivalent)
after the statements that send the headers, as displayed above.
If your script isn't written in Perl, do the equivalent thing for whatever language you are using (e.g., for C, call
fflush() after writing the headers).
Another cause for the "premature end of script headers" message are the RLimitCPU and RLimitMEM
directives. You may get the message if the CGI script was killed due to a resource limit.
In addition, a configuration problem in suEXEC, mod_perl, or another third party module can often interfere
with the execution of your CGI and cause the "premature end of script headers" message.
2.What does it mean when my CGIs fail with "Premature end of script headers"?
It means just what it says: the server was expecting a complete set of HTTP headers (one or more followed by a
blank line), and didn't get them.
The most common cause of this problem is the script dying before sending the complete set of headers, or
possibly any at all, to the server. To see if this is the case, try running the script standalone from an interactive
session, rather than as a script under the server. If you get error messages, this is almost certainly the cause of
the "premature end of script headers" message. Even if the CGI runs fine from the command line, remember
that the environment and permissions may be different when running under the web server. The CGI can only
access resources allowed for the User and Group specified in your Apache configuration. In addition, the
environment will not be the same as the one provided on the command line, but it can be adjusted using the
directives provided by mod_env.
The second most common cause of this (aside from people not outputting the required headers at all) is a result
of an interaction with Perl's output buffering. To make Perl flush its buffers after each output statement, insert
the following statements around the print or write statements that send your HTTP headers:
{
local ($oldbar) = $|;
$cfh = select (STDOUT);
$| = 1;
#
# print your HTTP headers here
#
$| = $oldbar;
select ($cfh);
}
This is generally only necessary when you are calling external programs from your script that send output to
stdout, or if there will be a long delay between the time the headers are sent and the actual content starts being
emitted. To maximize performance, you should turn buffer-flushing back off (with $| = 0 or the equivalent)
after the statements that send the headers, as displayed above.
If your script isn't written in Perl, do the equivalent thing for whatever language you are using (e.g., for C, call
fflush() after writing the headers).
Another cause for the "premature end of script headers" message are the RLimitCPU and RLimitMEM
directives. You may get the message if the CGI script was killed due to a resource limit.
In addition, a configuration problem in suEXEC, mod_perl, or another third party module can often interfere
with the execution of your CGI and cause the "premature end of script headers" message.
oups seems last message got repeated, sorry for that
ASKER
edicom,
when the FAQ says:
"Even if the CGI runs fine from the command line, remember
that the environment and permissions may be different when running under the web server. The CGI can only
access resources allowed for the User and Group specified in your Apache configuration"
is this referring to the lines in the
The httpd.conf file, which has:
User nobody
Group nobody
What does "nobody" mean? It seems to work fine for the firsttest script(?)
when the FAQ says:
"Even if the CGI runs fine from the command line, remember
that the environment and permissions may be different when running under the web server. The CGI can only
access resources allowed for the User and Group specified in your Apache configuration"
is this referring to the lines in the
The httpd.conf file, which has:
User nobody
Group nobody
What does "nobody" mean? It seems to work fine for the firsttest script(?)
The directives User and Group that are found in the httpd.conf file represent the user and group the server will be run as.
So if you have nobody for group and user, it means that the server will run as user nobody and group nobody. And so you cgi script will also behave as if it was run by user nobody (except if it s been compiled with suexec support for another user). Even if your server has to be started by root (for using port 80 for instance), it then changes to the user and group specified by these directives.
So you ll have to check you script logging as root and then su as nobody (nobody account doesn t have the ability to log directly), and see if it still running fine from console. Beside if your script relies on some environment variables, it seems you may also have troubles).
Regards,
So if you have nobody for group and user, it means that the server will run as user nobody and group nobody. And so you cgi script will also behave as if it was run by user nobody (except if it s been compiled with suexec support for another user). Even if your server has to be started by root (for using port 80 for instance), it then changes to the user and group specified by these directives.
So you ll have to check you script logging as root and then su as nobody (nobody account doesn t have the ability to log directly), and see if it still running fine from console. Beside if your script relies on some environment variables, it seems you may also have troubles).
Regards,
ASKER
edicom,
Thanks for your persistence!
I found one difference between the two scripts; The header line :
cout << "Content-type: text/html\n\n";
I can't believe I missed that one!
I placed the header lines at the begining of the script and the rest of the HTML output at the end of the script. This is because the whole thing takes about 15 to 20 seconds to run. However, now when I run the script from a web page, I don't get a server error, but I don't get all the output, either.
I suspect that there is timeout setting where the server will only wait so long for output from the CGI script.
Is this the case?
If so, do you know how I can find out what that timeout setting is?
Thanks,
Eric.
Thanks for your persistence!
I found one difference between the two scripts; The header line :
cout << "Content-type: text/html\n\n";
I can't believe I missed that one!
I placed the header lines at the begining of the script and the rest of the HTML output at the end of the script. This is because the whole thing takes about 15 to 20 seconds to run. However, now when I run the script from a web page, I don't get a server error, but I don't get all the output, either.
I suspect that there is timeout setting where the server will only wait so long for output from the CGI script.
Is this the case?
If so, do you know how I can find out what that timeout setting is?
Thanks,
Eric.
Well I don t know exactly, there s a TimeOut directive for httpd.conf, quoting the apache manual:
The TimeOut directive currently defines the amount of time Apache will wait for three things:
1.The total amount of time it takes to receive a GET request.
2.The amount of time between receipt of TCP packets on a POST or PUT request.
3.The amount of time between ACKs on transmissions of TCP packets in responses.
The thing is, it seems to default to 300, which is higher than your execution time.
Now what about putting the header lines just before the rest of the output in the script?
By the way, is the error/access log file saying something special about the script?
Regards,
The TimeOut directive currently defines the amount of time Apache will wait for three things:
1.The total amount of time it takes to receive a GET request.
2.The amount of time between receipt of TCP packets on a POST or PUT request.
3.The amount of time between ACKs on transmissions of TCP packets in responses.
The thing is, it seems to default to 300, which is higher than your execution time.
Now what about putting the header lines just before the rest of the output in the script?
By the way, is the error/access log file saying something special about the script?
Regards,
ASKER
OK, let me try putting all the HTML lines together.
In the mean time, where did you find the apache manual? I'm sure I have it here somewhere. What's the file name?
Eric.
In the mean time, where did you find the apache manual? I'm sure I have it here somewhere. What's the file name?
Eric.
Well I don t know exactly, there s a TimeOut directive for httpd.conf, quoting the apache manual:
The TimeOut directive currently defines the amount of time Apache will wait for three things:
1.The total amount of time it takes to receive a GET request.
2.The amount of time between receipt of TCP packets on a POST or PUT request.
3.The amount of time between ACKs on transmissions of TCP packets in responses.
The thing is, it seems to default to 300, which is higher than your execution time.
Now what about putting the header lines just before the rest of the output in the script?
By the way, is the error/access log file saying something special about the script?
Regards,
The TimeOut directive currently defines the amount of time Apache will wait for three things:
1.The total amount of time it takes to receive a GET request.
2.The amount of time between receipt of TCP packets on a POST or PUT request.
3.The amount of time between ACKs on transmissions of TCP packets in responses.
The thing is, it seems to default to 300, which is higher than your execution time.
Now what about putting the header lines just before the rest of the output in the script?
By the way, is the error/access log file saying something special about the script?
Regards,
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
edicom,
I've uped the points to 50. You've given me enough direction that I think I can figure it out from here. It still isn't displaying all the HTML, but I made another simple script that simply does the HTML output, the same as the websim script. That simple script is outputting just fine, so the problem is somewhere else in the websim script.
Thanks for your help.
If anybody reads this later, and wants to follow up on how the problem was solved (assuming I can solve it), email me at:
ewalstad@energywright.com
Eric.
I've uped the points to 50. You've given me enough direction that I think I can figure it out from here. It still isn't displaying all the HTML, but I made another simple script that simply does the HTML output, the same as the websim script. That simple script is outputting just fine, so the problem is somewhere else in the websim script.
Thanks for your help.
If anybody reads this later, and wants to follow up on how the problem was solved (assuming I can solve it), email me at:
ewalstad@energywright.com
Eric.
Thabk you, didn t noticed I posted as answer, sorry for that.
Maybe you can try writing to cerr in your script, I guess this will go in the error_log (as if you used a perl script with debugging on), so then you may figure where the script stops.
Regards,
Maybe you can try writing to cerr in your script, I guess this will go in the error_log (as if you used a perl script with debugging on), so then you may figure where the script stops.
Regards,
ASKER
edicom,
You didn't post as answer, I gave you the credit for answering it.
Thanks also for the tip on cerr. I've read about it, but never used it. I'll give it a try. I've got debug code that sends values to cout throughout the program, but cerr would probably be better.
thanks again,
Eric.
You didn't post as answer, I gave you the credit for answering it.
Thanks also for the tip on cerr. I've read about it, but never used it. I'll give it a try. I've got debug code that sends values to cout throughout the program, but cerr would probably be better.
thanks again,
Eric.
ASKER
I found the problem. The script has to open a couple of files during execution and it was looking in the wrong location for those files. Once the path's were ironed out, it started working fine.
glad to hear the problem s been solved. :o)