Fatal error messages are cached by proxy servers

[justdave]

If your wordpress blog is behind a caching proxy server, error messages such as "the database connection could not be established" get cached, so even after the database problem is fixed, you still have an error until you go flush the proxy server or wait for it to expire.

I understand that it's a bit difficult for PHP to tell a server to send a 500 error, but perhaps some cache control headers could be added to tell it not to cache.

[JeremyVisser]

+101. Additionally, this will stop Google from indexing the database error page.

I mean, if ​I can do it (look at the header() statements in some of the templates), why can't WordPress? ;)

[DD32]

Added

header("HTTP/1.1 500 Internal Server Error");

to the 2 error pages/functions( Database failing to connect, and wp_die())
Hopefully this should prevent the page from being cached(I assume based on JeremyVisser's template), while still showing a pretty error page to the Browsers.

[ryan]

If we do this the patch should use status_header()

[DD32]

If we do this the patch should use status_header()

Thats fine for in wp-includes/functions.php, however if the database is down, then the databse error is triggered before its included.

I've attached a new patch, It removes the html from wp-db.php, and calls wp_die instead, wp_die uses status_header().

I had to do a bit more hacking to make it work correctly, have a look at the diff for more info.

status_header() is defined in functions.php, so to use that for the database error, functions.php needed to be included first, Once doing that, i realised that the code was now duplicated in wp-db and wp_die, So i've got the datbase to just use wp_die(), and added a few extra checks in wp_die() to see if functions exist.

Also, If this gets slated for 2.4 rather than 2.3, the CSS location in wpdb->bail() points to the wrong location, so if this gets knocked back, that'll need fixing.

[DD32]

same as 3471.500.diff, but adds a pretty error message for bad table prefix rather than a plain one.

[markjaquith]

$title = function_exists('__') ? __($title) : $title; 

You can't use the translation functions like this (passing a variable). You'll have to do an if/else.

[DD32]

You can't use the translation functions like this (passing a variable).

Out of pure interest, What causes that?

[DD32]

change based on markjaquith's comment

[markjaquith]

Replying to DD32:

Out of pure interest, What causes that?

gettext is not a PHP parser, so it has no idea what is inside $title. So the issue is in generating the strings to be translated, for delivery to translators.

[markjaquith]

Applied the patch, shut down MySQL.

Got a HTTP/1.x 200 OK header, not a 500.

[DD32]

Got a HTTP/1.x 200 OK header, not a 500.

just rechecked, status_header() requires the filters to be loaded, and for the wp-includes/vars.php to be included as well(for the status desc.).

So, it doesnt look like its possible at this stage of the code(before DB is connected) to rely on status_header().
which leaves 2 options, hard code a 500 error into wp_die(), or hard code a 500 error(and duplicate the wp_die() html) into wp-db.php

i'll attach a patch which uses status_header() if hooks are loaded, else, hard code to 500

[markjaquith]

See:

[6104] and [6107], which make 3471.500.5.diff possible.

[DD32]

which make 3471.500.5.diff possible.

Looks good to me.

[markjaquith]

slight change, because of [6108]

[markjaquith]

(In [6110]) Use wp_die() for WPDB bails. Send 500 response and no-cache headers so wp_die()s are not cached. props DD32. fixes #3471