|
On debugging "Premature End of Script" errors
by merlyn (Sage) on May 06, 2003 at 14:42 UTC
|
Follow this easy sequence of steps:
- Make sure this works:
#!/bin/sh
echo content-type: text/plain
echo
date
(If you're not on Unix, you can skip this step, but
this reveals a lot about the CGI setup without having
to introduce the unknown of Perl.)
- Make sure this works:
#!/your/path/to/perl
print "Content-type: text/plain\n\n";
print "Hello world at " . localtime() . "\n";
- Now take your original script, and insert these
right after the #! line:
#!/your/path/to/perl
BEGIN { print "Content-type: text/plain\n\n--OUTPUT--\n"; }
... rest of your script ...
and make sure your code passes perl -c.
You should now see as the first few lines of output the exact headers and body sent by your program to the server. If the first lines up to the blank line are not nicely formatted headers, fix your script as needed. Once the headers are fixed, you can remove the BEGIN block.
Also, every time you see that sort of error, a sometimes-useful error message has been written to your web server's error log, so find that as well.
If you don't have access to the server log, a simple fix is to change step three's suggestion to:
BEGIN {
print "Content-type: text/plain\n\n--OUTPUT--\n";
open STDERR, ">&STDOUT"; # errors go to browser now
}
... rest of your script ...
And now the error messages show up in your browser, as if your browser was the result of invoking the script as a command line.
-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply. | [reply]
[d/l]
[select] |
|
|
Though the questioner said 'intermittent,' I'll also add the tip to make sure your script isn't using inconsistent line endings. A DOS-style \x0D\x0A at the end of the shebang line tends to confuse some Unix and Linux kernels. Perl doesn't mind but the kernels do.
Try running (dos2unix) on the script file, or the equivalent (perl -pie 's/\x0D//g' file).
Many editors often hide this problem *unless* the line endings are mixed within the same file: they figure you know what you're doing, or you don't know what line ending differences are.
--
[ e d @ h a l l e y . c c ]
| [reply] |
|
|
I think this an excellent answer to what seems to be a common question. I was surprised that a question like this wasn't already in the Categorized Q & A. I'd like to this the question with this answer appear there.
Mark
| [reply] |
|
|
Depending on which version of perl you got, you will get one of the following from perldoc -q 500
My CGI script runs from the command line but not the browser. (500 Server Error)
Several things could be wrong. You can go through the
"Troubleshooting Perl CGI scripts" guide at
http://www.perl.org/troubleshooting_CGI.html
If, after that, you can demonstrate that you've read the FAQs
and that your problem isn't something simple that can be easily
answered, you'll probably receive a courteous and useful reply
to your question if you post it on
comp.infosystems.www.authoring.cgi (if it's something to do with
HTTP or the CGI protocols). Questions that appear to be Perl
questions but are really CGI ones that are posted to
comp.lang.perl.misc are not so well received.
The useful FAQs, related documents, and troubleshooting guides
are listed in the CGI Meta FAQ:
http://www.perl.org/CGI_MetaFAQ.html
older
My CGI script runs from the command line but not the browser. (500 Server Error)
If you can demonstrate that you've read the following FAQs and
that your problem isn't something simple that can be easily
answered, you'll probably receive a courteous and useful reply
to your question if you post it on
comp.infosystems.www.authoring.cgi (if it's something to do with
HTTP, HTML, or the CGI protocols). Questions that appear to be
Perl questions but are really CGI ones that are posted to
comp.lang.perl.misc may not be so well received.
The useful FAQs and related documents are:
CGI FAQ
http://www.webthing.com/tutorials/cgifaq.html
Web FAQ
http://www.boutell.com/faq/
WWW Security FAQ
http://www.w3.org/Security/Faq/
HTTP Spec
http://www.w3.org/pub/WWW/Protocols/HTTP/
HTML Spec
http://www.w3.org/TR/REC-html40/
http://www.w3.org/pub/WWW/MarkUp/
CGI Spec
http://www.w3.org/CGI/
CGI Security FAQ
http://www.go2net.com/people/paulp/cgi-security/safe-cgi.txt
This should be the first response to every question dealing with perl and error 500.
The 2nd response should be "where's the sourcecode?" | [reply] |
Re: Premature End of Script Headers Reasons?
by hardburn (Abbot) on May 06, 2003 at 14:36 UTC
|
It's almost always one of two things:
- The script dies before sending the Content-type
- Something gets printed to STDOUT before the Content-type
If there is another situation where this comes up, I've never seen it. Things printed to STDERR don't matter (unless you have a weird web server, in which case you have other problems).
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
Note: All code is untested, unless otherwise stated
| [reply] |
Re: Premature End of Script Headers Reasons?
by Enlil (Parson) on May 06, 2003 at 14:36 UTC
|
There are links the in the documentation that comes with Perl ( perldoc perlfaq8 ) also if you are running Apache as the web server there is some troubleshooting tips here. (first thing i would do though is check that it runs at the command line.. and then go from there)-enlil | [reply] |
Re: Premature End of Script Headers Reasons?
by Your Mother (Archbishop) on May 06, 2003 at 18:51 UTC
|
There's some good info above for why things go wrong. And trouble shooting advice from the command line. But CGIs often behave very differently from the command line b/c of permissions or even paths.
My favorite trouble shooting tool is use CGI::Carp like so use CGI::Carp qw(fatalsToBrowser); Usually, that will identify the problem to you immediately (you can always check your error logs too depending on how they're configured but I like the module better).
Do not add this into a production script. It can give away functional details about the CGI or your system to potentially malicious users. You could copy the CGI to a new name (and path?) and set it to only accept a particular user or local connection and then add it. Then just run it till it dies and spits out the reason and not just a generic 500. Make sure you have good error catching routines in your script too to ensure the best information in the die'ing.
| [reply]
[d/l] |
Re: Premature End of Script Headers Reasons?
by phildog (Novice) on May 06, 2003 at 17:19 UTC
|
this came up for me today, here's what was wrong
#which perl
/usr/bin/perl
your script:
#!/usr/local/bin/perl
my solution (as root):
ln -s /usr/bin/perl /usr/local/bin/perl
sure, you can fix your #! line in your scripts too if that makes you feel better! | [reply] |
Re: Premature End of Script Headers Reasons?
by markjugg (Curate) on May 06, 2003 at 17:56 UTC
|
If you are one of the few people running scripts under Apache's "suexec" system, there are more problems that can come up, and there won't be any useful messages about them in the standard web server log. <a href="http://httpd.apache.org/docs/suexec.html"Read about more about SuExec. for details.
On my system, I can look at /var/log/httpd/suexec_log to see if there was an SuExec related error.
-mark | [reply]
[d/l] |
Re: Premature End of Script Headers Reasons?
by samtregar (Abbot) on May 06, 2003 at 19:49 UTC
|
It's unlikely that you're having this problem, but Apache 2.0 nearly drove me out of my mind with that exact message because suexec was turned on. Check out my tale of madness here.
-sam
| [reply] |
Re: Premature End of Script Headers Reasons?
by Gilimanjaro (Hermit) on May 07, 2003 at 12:49 UTC
|
Two tips:
- Very nice module to use: CGI::Debug
- If not on win32, make sure your shebang line (#!/usr/bin/perl) doesn't have a \r\n combo instead of just a \n at the end; bash doesn't strip the \r and looks for an executable named perl with the carriage return special character appended... This one pops up every now and then if you edit your scripts on a WinDOS platform..
And off-course I cannot ommit my usual PLP advocacy... :)
| [reply]
[d/l]
[select] |