Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I have a simple SOAP service on an IRIX box to perform queries on an Oracle database hosted on a remote SUN box. Calls to the SOAP service are dispatched via a CGI script. For testing purposes, I have a simple client program on the IRIX box to submit the SOAP call and process the response. This service works fine locally on the IRIX box. It even works when I call the service on the IRIX box using the same client program on a remote LINUX box. However, when I copy the service source code files to the LINUX box and try to run the service locally, I get the dread "500 Internal Server Error" message and the error_log simply says "Premature end of script headers:...".

My SysAdmin has assured me that we're running the exact same version / configuration of Apache and PERL on both the IRIX and LINUX boxes. Since the source code runs fine on IRIX, I'm at a loss as to why it won't run under LINUX. I have confirmed that I have access to the remote database from the LINUX box. I also have strong evidence that the queries are actually being processed by the database, but that something is going wrong while the query result is being returned. The client dies without even letting me check the faultcode or faultstring. Help!

Replies are listed 'Best First'.
Re: Problem: SOAP via CGI with PERL
by wazzuteke (Hermit) on Dec 13, 2005 at 20:54 UTC
    I would first try:
    #!/usr/bin/perl use strict; use warnings; use CGI; # Assumption use CGI::Carp qw( fatalsToBrowser ); # Rest of the code
    This will translate your Perl errors and send the output to the browser.

    The "Premature script headers" can sometimes be someting that is easily missed and easier to fix.

    Try the following if the above snipped doesn't help much:
    print "Content-type: text-html\n\n";
    This will provide the output with enough headers to be processed as an HTML document.

    If the content-type is not the issue, I would certainly make sure you debug with the Carp snippet. You can, naturally take out the 'use' when you're finished debugging, however it will usually point you in the right direction of the problem.

    Also, make sure the file permissions are satisfactory to execute on the server. You should be safe with chmod 755 <FILE> (-rwxr-xr-x) if not already set this way.

    Good luck!

    ---hA||ta----
    print map{$_.' '}grep{/\w+/}@{[reverse(qw{Perl Code})]} or die while ( 'trying' );

      Printing a content-type is a good idea, but it won't always work -- you'll want to turn output buffering off, just in case something throws an error before the print buffer gets flushed, and even then, it might not get to the print statement if something happens in a BEGIN block. (and well, 'use' counts as a BEGIN block.

      Based on the error message, I doubt it's a permissions problem, but I would make sure that the file passes 'perl -wc filename' from the command line -- it'll let you know if there's something blatently wrong with it (like missing modules, which is a distinct probability when switching systems, even when the perl versions are the same)

      Oh -- and for debugging, I love CGIwrap. It handles processing limits on my CGIs and keeping them from running as the webserver, and a quick change to the URL, and it'll spit debugging info back to you.

Re: Problem: SOAP via CGI with PERL
by phaylon (Curate) on Dec 13, 2005 at 19:52 UTC
    Have you tried CGI::Carp from the CGI Distribution?

    Ordinary morality is for ordinary people. -- Aleister Crowley
Re: Problem: SOAP via CGI with PERL
by mda2 (Hermit) on Dec 14, 2005 at 18:15 UTC
    Usually SOAP::Lite require many modules. Can you execute via shell ?

    If don't, try one code like code:

    eval " use PM::Rio; "; if ( $@ ) { print "Required module PM::Rio unavailable...\n"; } else { print "Loaded ;)\n"; }

    More info on SOAP::Lite prerequisites...

    --
    Marco Antonio
    Rio-PM