(A work in progress.)
One of the biggest problems with developing dynamic content for your site, is when things go wrong. Most of the error messages displayed in the
browser don't really give any useful information about what the error actually is, or how to fix it.
Believe it or not, but that's usually on purpose. Think about it, if your script gave a big error message detailing all manner of things about your server, like file paths,
permissions or database settings, would you really want just anybody to be able to see it?
So where does that leave you? well we are going to discuss some of the common error messages, and what hints they give us with regards to fixing them.
The first 3 error messages detailed here are actually related and often relate to the same common problems. These messages, or variations of them can come from any
script based server side language, be it Perl, PHP, Pythod or something else. Most of these error messages are generated by the web server software so they are not really
language specific.
If you are going to be dealing with lots of scripts, and you don't have access to your server error log, it is to find yourself a new host that does give you that access. It
may not sound like a big thing, but having access to a server error log can save you hours upon hours of time debugging. Good luck!
The "Premature end of script headers" error message is probably the most loathed and common error message you'll find.
What the error actually means, is that the script stopped for whatever reason before it returned any output to the web server.
A common cause of this for script writers is to fail to set a content type before printing output code. In Perl for example, before printing
any HTML it is necessary to tell the Perl script to set the content type to text/html, this is done by sending a header, like so:
print "Content-type: text/html\n\n";
If you don't do that, Perl will try to output to STDOUT (Standard Output, or the servers terminal) instead of through the web server to your browser.
The same applies to any CGI script of any language.
The problem might be the script itself, for example, say you have a formmail type script that is trying to send an e-mail to sendmail on the server, but the path
to sendmail in the script is wrong or has passed bad parameters. The script should die at this stage and print an error message to the server error log, saying that
it was "unable to open sendmail" or some such error, but you will see an error like "Internal Server error" or "Premature end of script headers" because printing detailed
error messages to an unknown users browser is giving to much potentially damaging information away to possibly untrustworthy people.
With Perl there is something you can try that will attempt to redirect error messages to the browser so you can attempt to diagnose the problem.
Open the script in your text editor, and under the path to Perl on the first line, place this:
use CGI::Carp qw(fatalsToBrowser);
Then upload the script again, set it to executable and point your browser at it. If all goes according to plan, the error message will now be printed
to the browser for all to see. Fix the error it details, and then comment out (or remove) that line because its never a good idea to give server settings out.
We are sorry, but there is no quick and easy explanation for this error. Simply because all the error really says is "it didn't work". So in short
the answer may be simple, but this error message isn't going to tell you what it is.
Permissions, ascii & binary file uploading and script configuration (are the required files where the config says they should be?) are the things most likely to cause such an error.
[top]
This one is nasty and gives very little information about what is going on.
Here is an example.
The example script causing that error above, is a perfectly legit/valid "hello world" script, and I was able to generate this error simply by setting the permission on the file
to 700 instead of 755, meaning that only the user owning the file was able to execute it, not the user the web server software runs under.
For more information on server permissions, see
here.
Normally, when asked how these errors are caused, my first suggestion (or question in this case) is "what does the server error log say about it?"
however in this case, the only error message in the log is: Premature end of script headers: error2.pl so my advice in this case, is that if you get the
internal error message the first thing you should do is check your file permissions, after all, if a script can't execute, it can't generate a useful error message.
So, first thing to check after getting one of these error messages, is to find your servers error log, (if you don't know where it is, you should ask your hosting provider).
If your error log doesn't provide any useful message, the next thing to do is check your file permissions, scripts should generally have permissions of 755.
The other thing to check is how you uploaded the script, did you upload it as binary or ASCII? if its a script file like Perl, or UNIX shell, or PHP,
(by script I mean a program you can open in a text editor and read the code.) you should have uploaded it as a text file (ASCII).
If the file a C or C++ or other compiled program, you should upload it as "binary". Getting that wrong will result in a script that simply will not work, and the only
recourse is to delete the file off the server and upload it again with the correct type set.
Lastly is another common problem with script files. end of line characters.
Unfortunately, windows, Unix/Linux/*BSD and Mac all have different return characters, (the characters that denote end of line or "return characters")
This can cause problems because quite often, they are not at all compatable. In particular, windows return characters will often cause a UNIX perl or shell script
to die with a relatively useless error message, because the Perl or shell interpreter doesn't know how to "interpret" them.
More often then not, these errors are caused by editing a file on one platform, (like windows) and uploading .the file to a different platform. (like Linux).
The solution is pretty simple really. First get yourself a decent text editor like Textpad.com or Notetab.com.
These editors will allow you to change the format of a file between the different variations, or allow you to change them appropriately.
My experience, is that "when in doubt" use the UNIX file format, as it will cause no problems on widows machines and should be good to go with all other variations as well.
[top]
No difference between this error and the one above, the same recommendations apply.
The 500 is just an Apache error code designating an internal server error.
[top]
This one is also not very specific to the problem and can be grouped into the same category as Internal Server Error and
Premature end of script headers, basically what they are all telling you is that the script died before it could return anything that the web server
could send to the browser. Usually this means the permissions are bad, or the script doesn't have permission to run, or that some misconfiguration in the script
has caused it to die with an error before it could return anything useful. The same advice as the above mentioned errors applies here.
[top]
Also shows up as:
"Can't locate XX.pm in @INC. BEGIN failed--compilation aborted."
This one is a pretty simple to explain Perl error. In short, a required module, (code library) that your script needs is not installed or not locatable
on the server.
You have a couple of options, one is to have the host install the module. (or at least ask) the second is to install the module in your home directory.
(only an option if you have shell access to the server, like Telnet or SSH).
You can find a good tutorial on how to install Perl modules as a user here.
[top]
Also shows up as:
"perl: warning: Please check that your locale settings:"
If you are using remote web hosting as opposed to having your own dedicated server then there is not that much you can do about this one
as it should be fixed by root user system wide. This is not usually a fatal error as there is usually a fallback local that will be used
if the configured one is not available. (or if there is no configured one.) If the server is your own, then you need to look into the method by
which the server OS configures its locale. For example in Debian Linux you would install and run localeconf. In RHEL or CENTOS you
might give editing /etc/sysconfig/i18n a try. The documentation for your OS will tell you what you need to know.
[top]
Basically a user/password error. The password "YES" doesn't mean that you put yes as a password, it just means that yes a password was given but it was wrong for that user or this database.
It says yes instead of giving you the password used incase you are not a person who should see said password.
The solution is pretty simple, check that you have the right database name, and then check your user/password credentials.
One of them (or your syntax) will definately be wrong.
[top]
In the case above, it means that a table called foo in your MySQL database has become corrupted. To repair it you
can try running mysqlcheck from the command line in the format: mysqlcheck [options] my_db_name [table_name]
You can also use phpMyAdmin to repair the table if you do not have shell access to the server. Browse to the table in question in phpMyAdmin,
select the "Operations" tab and in a box to the right is a "Repair table" option.
[top]
Also shows up as:
"Notice: Undefined offset: baa"
You have messed up inserting data into a db somehow, for instance a variable in your SQL that should have a value, doesn't.
This happens sometimes when people don't validate user supplied data before putting it into a DB. If you are not sure which one it is
try printing the values to screen (or write them to file) rather than putting them in the DB so you can see what their actual values are.
Oh, and always validate user supplied input and don't assume they will have filled out a form (for example) correctly or completely, so you have
to check everything they entered before using it. (start looking at regex)
[top]
This is an error message produced by the MySQL database when you pass it a request that doesn't match
the output variables that you have provided..
Don has already covered this common error
here so I'd rather direct you there then explain it from scratch. :-)
[top]
OK, This message can be a permissions problem, but it seems to show up now days more in the context of a mod_security
conflict.
ModSecurity is a lovely Apache module designed to help server admins stop nasty people doing nasty things to other peoples webservers.
It records and blocks what it considers to be nasty behaviour before it can do any harm.
Sometimes however it blocks programs that really didn't deserve such scrutiny and that is when you'll get the Forbidden You don't have permission to access.... message.
Fortunately it is usually pretty easy to get around this message. (after you have verified why you are getting it.)
All you need to do, is create a file called .htaccess in that directory, and put the following into it.:
<Files bar.cgi> SecFilterInheritance Off </Files>
Obviously bar.cgi should be replaced by the name of the file you are having troubles with, and it should be saved to the directory
containing that file. (in my example here that would be directory /foo).
Assuming that your server is configured to follow htaccess files, you should no longer have a problem. (and if it doesn't work, you'll probably have to ask your host
to fix it in the Apache config settings for your account)
I know that ModSecurity can effect the latest versions of Wordpress (The admin front page losses bits due to ModSecurity)
and CGI::IRC also has an issue with client-perl.cgi or client.cgi kicking up the error. There are no doubt many more.
[top]
Those are all the common error messages I can come up with off the top of my head at this time. (2.30 in the morning.) as I come across more, I will add them to the list
so this will hopefully become a living document that will expand continuously as time goes on. If you think of an error you think I should add,
use the HTMLfixit contact form to let me know.
Happy Hunting :-)