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-Language" CONTENT="en-us">
</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!
ewalstadAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

edicomCommented:
well, what s the apache error_log file saying?
0
ewalstadAuthor Commented:
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.
0
edicomCommented:
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.
0
Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

edicomCommented:
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.
0
edicomCommented:
oups seems last message got repeated, sorry for that
0
ewalstadAuthor Commented:
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(?)
0
edicomCommented:
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,
0
ewalstadAuthor Commented:
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.
0
edicomCommented:
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,
0
ewalstadAuthor Commented:
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.
0
edicomCommented:
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,
0
edicomCommented:
you probably got the manual in the htdoc directory under manual, else it s available on http://www.apache.org/docs/, the main thing being the runtime directives section.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ewalstadAuthor Commented:
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.
0
edicomCommented:
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,
0
ewalstadAuthor Commented:
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.
0
ewalstadAuthor Commented:
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.
0
edicomCommented:
glad to hear the problem s been solved. :o)
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux Networking

From novice to tech pro — start learning today.