Database: Send a 500 status and no-cache headers when using db-error.php or maintenance.php drop-ins - #13471
Database: Send a 500 status and no-cache headers when using db-error.php or maintenance.php drop-ins#13471dineshinau wants to merge 6 commits into
Conversation
…php or maintenance.php drop-ins
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @thedineshy@gmail.com. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
Co-authored-by: Weston Ruter <westonruter@gmail.com>
Co-authored-by: Weston Ruter <westonruter@gmail.com>
Fixed the status header for wp maintainance to change 500 to 503 in comment line
|
@westonruter Addressed your requested changes — fixed the PHPCS issues and corrected the status header from 500 to 503 in the comment above wp_maintenance(). Ready for another look whenever you have time. |
Currently, when a site uses a db-error.php or maintenance.php drop-in to show a custom outage page, WordPress skips the status_header() and nocache_headers() calls it normally sends via wp_die(). This means a 500/503 page can get cached as a 200 by a CDN or reverse proxy (e.g. Varnish), leaving a stale error page served long after the outage is resolved.
This adds status_header( 500 ) + nocache_headers() before loading db-error.php, and status_header( 503 ) + nocache_headers() + the existing Retry-After header before loading maintenance.php.
Note there are two separate places that load db-error.php: the dead_db() function in wp-includes/functions.php (used when a query fails mid-request), and a duplicated inline check in WPDB::db_connect() (used when the initial connection attempt fails). Both needed the same fix, since they don't share code.
Tested by forcing a connection failure via invalid wp-config.php credentials (exercises class-wpdb.php) and by creating a .maintenance file (exercises wp_maintenance()), confirming via
curl -Ithat the correct status code and Cache-Control: no-cache headers are now sent in both cases.Trac ticket: https://core.trac.wordpress.org/ticket/66080
Opened from the WordPress Contributor Toolkit.