wordpress errors return status 200

[glub]

Wordpress notices when a page doesn't exist or the database is down and
returns a human-readable error. However, the HTTP status code for these
pages remains 200. This means the page looks like a "real" page to
monitoring systems and programs like wget.

This bug is to request a change to the themes/default/404.php file and wp-includes/wp-db.php
file. Basically wordpress should call the php header() function to set the return
header when there is an error.

Here are the diffs that will accomplish this:

Index: wp-includes/wp-db.php
===================================================================
--- wp-includes/wp-db.php	(revision 420)
+++ wp-includes/wp-db.php	(working copy)
@@ -42,6 +42,7 @@
 	function wpdb($dbuser, $dbpassword, $dbname, $dbhost) {
 		$this->dbh = @mysql_connect($dbhost, $dbuser, $dbpassword);
 		if (!$this->dbh) {
+			header('HTTP/1.0 500 Database Not Available');
 			$this->bail("
 <h1>Error establishing a database connection</h1>
 <p>This either means that the username and password information in your <code>wp-config.php</code> file is incorrect or we can't contact the database server at <code>$dbhost</code>. This could mean your host's database server is down.</p>

Index: wp-content/themes/default/404.php
===================================================================
--- wp-content/themes/default/404.php	(revision 420)
+++ wp-content/themes/default/404.php	(working copy)
@@ -1,3 +1,4 @@
+<?php header('HTTP/1.0 404 Not Found'); ?>
 <?php get_header(); ?>
 
 	<div id="content" class="narrowcolumn">

[NathanWong]

The wp-db.php error should be in wpdb::bail(), I think, instead of right before the function is called (or a standalone error handling class, really, but that's a different problem).

[markjaquith]

+1 for the idea

+1 for Nathan's suggestion of putting the 500 error in wpdb::bail();

[markjaquith]

Patch adds 500 error to wpdb::bail()

I also modified status_header() to accept 500 and also to optionally accept alternative $text messages.

Adding header() to the top of a template file is a bad idea, however... and that's really a separate issue than WP errors.

[markjaquith]

Any thoughts on this patch?

[davidhouse]

Perhaps we should include a general Status Code -> Message lookup array, pulled from the RFCs. So we can feel comfortable passing anything into it.

[markjaquith]

Yeah, would be cleaner. Those if() else if()s are about at capacity.

[davidhouse]

I'll get on to this tonight (in about 6 hours) if you can't in the mean time.

[technosailor]

This should be a 503 Service Unavailable error, not a 500 Internal Server Error. 500's are generally reserved for Web server configuration errors (i.e. Perl permissions, .htaccess/httpd.conf errors).

​http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

[davidhouse]

Patch attached which replaces MarkJaquith's: send a 503 and include a resp code -> message array in vars.php with an accessor func, header_num_to_desc().

[trevorturk]

Is this fixed by:

​http://trac.wordpress.org/ticket/3166

...?

[foolswisdom]

leflo commented in #3166 that it will not fix this issue. "It won't fix anything where wp_redirect isn't called."

[rob1n]

Okay, new patch does everything. Not so sure about the placing of the 404 one in WP_Query, though.

[rob1n]

(In [5446]) New status_header code, and WP-DB bail() errors send a 503 Service Unavailable. see #2409

Also, the new header code to text array has 302 as Found. fixes #4183

[rob1n]

Okay, that was the first half. Now we (I) need to figure out where to put the 404. I had it in WP_Query (didn't commit it), but that doesn't feel right. Maybe wp-settings.php, after WP_Query is initiated?