09/30/2005

Premature end of script headers

As anyone dealing with Perl .cgi scripts may have run into the dread premature end of script headers error, I thought I'd post the above link from htmlfixit.com. The title is apt: "Server error messages, the bane of web developers everywhere".

That page, intelligibly written for those of us who are only somewhat versed in Perl coding, helped me to debug a script recently. Actually, the answer wasn't on the page, but it did give me the hint/clue that solved my problem. :)

<Added>

And this is terrific for debugging errors (put it right under the path to Perl). What it does it send the error message to the browser.

use CGI::Carp qw(fatalsToBrowser);

20 Comments to "Premature end of script headers"

  1. Michael Bianchini says:

    Hello! I tried using the use command listed above. I put it right underneath the first line of my script so that it looks like this:

    #!/usr/bin/perl
    use CGI::Carp qw(fatalsToBrowser);

    etc. And when I run I just get the default message:

    Server error!

    The server encountered an internal error and was unable to complete your request.

    Error message:
    Premature end of script headers: FormMail.cgi

    If you think this is a server error, please contact the webmaster

    Error 500

    localhost
    Sun 23 Jul 2006 10:39:35 AM EDT
    Apache/2.0.40 (Red Hat Linux)

    I am running Red Hat Linux v9, Mozilla Firefox v1.0, and Perl v5.8.0 and the Apache Web Server v2.0.40.

    Any suggestions?

    Thanks!

  2. Diane Vigil says:

    Hi. Did the script run at all before you inserted that line? And were the permissions set correctly?

    There's more information here: Server error messages, the bane of web developers everywhere.

  3. Michael Bianchini says:

    Hello! Thanks for responding!

    I was able to solve my original problem (same error) without actually using the fatalstoBrowser. You're right, I had to open up execute permissions for all users on my home directory, which eventually led to the directory that I was using as my DocumentRoot.

    So yes, the script now runs fine without that line. If I put the line back in, I still get the error. I had already looked at the link you mentioned, but it simply tells me to use the fatalstoBrowser. I found another link (URL provided) that seems to indicate that "some servers do not support this technique." Could it be that mine doesn't? Old version of Apache or something?

    Thanks again for your help. At least my script is working now! :)

    – Mike

  4. DianeV says:

    Yes, that would be it — not all servers are set up to run everything.

    I'm glad the script runs now. And, yes, you have to set the permissions on Perl scripts so that they can be executed via the website (755). It's always something to remember. :)

  5. murali says:

    Thank you! It works. It returned the actual error (which was that I had put a " in a " bracket, a big no no!

    Like this:
    $errmsg = ""Username" mesti di isi!\n" ;

    It should be:
    $errmsg = "'Username' mesti di isi!\n" ;

    Thanks!

  6. Diane Vigil says:

    Excellent, Murali! Glad it was of help — and thanks for your explanation. No doubt it will help others.

    However, I think your comment was meant to be here:
    WordPress & Akismet: a little code blocker

  7. Franki says:

    Hi guys,

    That line:
    use CGI::Carp qw(fatalsToBrowser);

    will not work if the script can't run. What I mean is that the above line is a line of code. If the script has been uploaded as binary, or the permissions are wrong, it will not get run and therefore will not send anything useful to the browser.

    It's saved me lots of time troubleshooting other problems though.

    regards

    Franki
    htmlfixit.com

  8. Diane Vigil says:

    Good point, Franki. That's one of those things that goes unmentioned because it's so obvious; the kind of thing that I just hate when I run into it. And now I've done it, too. :) Thanks for pointing it out.

  9. John Miller Crawford says:

    Brilliant! Thanks so much, Diane, for showing up in Google on a "Premature end of script headers" search – immediately told me what was going wrong (Can't localize lexical variable).

  10. Diane Vigil says:

    You're very welcome, John. Glad it was of help to you.

  11. Sneha says:

    Thank you so much, I google whole day but did not find anything. But this post seems useful. It helped me to figure out the error. I was banging my head in wall whole for "Premature end of script headers". Thank you!! You saved me from trouble!

  12. Diane Vigil says:

    You're very welcome, Sneha — and I truly understand what you mean!

  13. Alex Belmar says:

    Hi:
    I have the same error, here is my issue:

    I have my apps at a Red Hat Linux, it is not my preferred.
    The ISP where is the service that i am using has a very complex control panel that use Perl with a very sophisticated configuration that force me to run under a vitualhost section.
    I can run, for example, php and python with no problems, but the other perl applications that work over FreeBSD unix and solaris with no problems, didnĀ“t run there.
    I tried adding the line that you recommend, but nothing happened, also I checked the permissions and all is ok, the files are in ascii format
    Some ideas?
    , thanks in advance.

  14. Diane Vigil says:

    Hm. Is Perl running on the server, and is the path to Perl correct in your script? (I presume you've set the correct permissions, or you would have gotten an error page.)

    ADDED: Your ISP may have some .cgi scripts uploaded; you might take a look at those to see how they specify things.

  15. Alex Belmar says:

    thanks, for your quickly response, the path is right, but i discovered that the problem is other.

    I think that the problem is that the server runs under suexec policies.

    I get no more the header error message, i am getting an other one, to be honest is the very first time that i am working under suexec policies, but is mandatory with this ISP.

    the new error that i am investigating is this:
    [2010-08-31 16:27:13]: uid: (500/abelma1) gid: (48/48) cmd: test01.cgi
    [2010-08-31 16:27:13]: cannot run as forbidden gid (48/test01.cgi)

    I set the SuexecUserGroup to abelma1 apache at section.
    the directory that contains all the scripts, has abelma1 as the owner and apache as the group and all the files and directories under it has the same ownership.

    Thank in advance for your help

  16. Diane Vigil says:

    I'd contact your web host about that. I did find a discussion about it:

    http://linux.derkeiler.com/Mailing-Lists/RedHat/2004-04/0128.html

    which says:

    In any case, I ended up changing the GID of users from 100 to 500 in /etc/groups and changed the user's default group in /etc/passwd from 100 to 500 and reset the ownerships on their files. Everything seems to be working now.

    Its odd because the scripts in /var/www/cgi-bin can be owned by anyone and run so that pretty much does away with the security precautions…

    However, I haven't dealt with this and don't know what that might affect, so I'd contact your web host.

  17. Alex Belmar says:

    sorry for the replay, at the first message where edition errors, here is the good one:

    Hi!!

    Thanks for all your support.

    Here is the solution and some concepts that i could find during this troubleshooting process for perl in RedHat and the use of suexec policies:

    at the <virtualhost adress:port> section we must put the following line
    SuexecUserGroup username username

    where "username" is the name of user that own the path where the html & cgi files are located: example /home/abelma1 below this directory are the following subdirectories: www/"virtualhostname"

    The full path is "/home/abelma1/www/abelmar.net" this could be the value of your ScriptAlias directive inside the same section:

    ScriptAlias /cgi-bin/ "/home/abelma1/www/abelmar.net/"
    The complete example:

    <VirtualHost adress:port$gt;
    SuexecUserGroup abelma1 abelma1
    ServerName abelmar.net
    ServerAlias http://www.abelmar.net
    ServerAdmin webmaster@abelmar.net

    Alias /abelmar.net/ "/home/abelma1/www/abelmar.net/"
    ScriptAlias /cgi-bin/ "/home/abelma1/www/abelmar.net/"

    DocumentRoot /home/abelma1/www/abelmar.net

    <Directory /home/abelma1/www/abelmar.net>
    AllowOverride All
    Options Includes Indexes FollowSymLinks ExecCGI MultiViews
    Order allow,deny
    Allow from all
    </Directory>
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteOptions inherit
    </IfModule>

    .
    </VirtualHost>

    At cgi files level and directory level too, we need to assign them the owner "abelma1" as user and we need to assign the same user name "abelma1" as a group name, where "abelma1" is the user that manage apache for certain path.

    What cause the problem on a virtual host schema:
    if suexecUserGroup user and group are different to the owner of the path indicated at the DocumentRoot directive inside the <virtualhost…> section at the configuration file of apache, the suexec policies give us an error 500 at server and the execution of cgi is aborted.

  18. Diane Vigil says:

    Ah, interesting. Thanks for the update.

  19. Madhu says:

    Hi

    I am getting the error:

    Server error!

    The server encountered an internal error and was unable to complete your request.

    Error message:
    Premature end of script headers: greeting.pl

    As updated in this blog, I updated the permissions for the folder and also tried everything but the error still stays.

    could you help me

  20. Diane Vigil says:

    Not really, since I don't know what your greeting.pl has in it, nor what you tried.

    Scroll to the top of this page, and click on the "premature end of script headers" link. That may give you the information you need.

Have your say ...

First-time comments will be held for moderation (but comments are appreciated). Otherwise, just be courteous. If your name is a bunch of keywords, your comment will be deleted. Don't post links unless highly pertinent. Posters must be 16 or older.

Manage your subscriptions

Archives
© 2004-2017 DianeV Web Design Studio. All Rights Reserved.
34 queries. 0.228 seconds.