Fixing the WordPress HTTP-500 error

2008-03-16 22:44 by Ian

There has been a good deal of frustration from WordPress users regarding this error message when using WordPress:
“The application misbehaved by not returning a complete set of HTTP headers.”
Alternately known as an HTTP-500 error.

Sol (in server operations) found out exactly what was wrong and why. It turns out that I encountered this problem in different dress last year, so he asked me to do the write up.

Recent versions of WordPress were having problems that can be traced back to wp-db.php. The generic error message caused people on various forums to point the finger variously at fast-cgi/IIS, PHP4, WordPress, and even MySQL. The answer lies on line 163 of wp-db.php, where we see…

error_log($error_str, 0);

It isn’t WordPress. Their application is fine, and only fails in this manner in IIS because of the permissions set to the log file that the error_log function writes to. That log file is determined in PHP.ini and php.exe doesn’t have write-access to it.

I have reposted my response to a ticket regarding PHP formmail. The offending line in formmail was 556, and was the exact same function call. The solution is also the same.

The server is fine. The problem is a permissions/configuration related one.
The function call that I removed writes a message to whatever destination type is specified in the second argument of error_log(). See this page for details….
http://www.php.net/manual/en/function.error-log.php

To see where this error gets sent, you need to run this simple PHP script on your domain:
<?php echo(phpinfo()); ?>

Doing so will display all the PHP settings.

Then search the page for “error_log”.
...we can see that these messages will be directed to php_error.php (throws a 500 error).

What you are seeing is normal behavior.

If you decide you want the logs you should change the error_log() call’s second argument to something other than zero. Again, referring to the php.net article on this function…

“2” is not an option, as PHP is built for a production environment. It shouldn’t work.

“3” is certainly an option, but you will need to set proper permissions to a log file. Also make sure that the logs don’t eat all your free-space.

“1” is also a good option if you already have a script setup to send mail from PHP. See the script in the Knowledge Base for a free script for this purpose.

If you are the self-teaching type, you might also find something more creative to do with the message. I might choose to insert the message into a DB. That way I could filter out the webserver’s IP and time-date stamp it. Thereby giving you ONLY the hits to the script that DON’T come from the webserver.

Recapping…
Your server is fine.
If you want logging, you now have all the info you need to enable it.
If you don’t want logging, your script will work fine by commenting out line 163 in wp-db.php.

Hit me up with questions.

Previous:
Next: