Make WordPress Core

Opened 2 years ago

Last modified 17 months ago

#55610 new defect (bug)

HTTP response should not be 200 when returning error-page

Reported by: april213's profile april213 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: major Version:
Component: HTTP API Keywords:
Focuses: Cc:

Description

Current behavior:
When WordPress web site was under high concurrency access, the database connections may reach the limitation of the system resource. WordPress was still returning 200 of HTTP response code when database connection error happens.

The page with error information as:
Error establishing a database connection
This either means that the username and password information in your wp-config.php file is incorrect or we can't contact the database server at dbhost. This could mean your host's database server is down.

Expected behavior: Returns HTTP code with 500 or other error codes to indicate error happens, when showing error pages.

Attachments (1)

wp_db_error.png (37.0 KB) - added by april213 2 years ago.
Error page snapshot

Download all attachments as: .zip

Change History (5)

@april213
2 years ago

Error page snapshot

#1 @sabernhardt
2 years ago

Hi and thanks for the ticket!

Possibly related: #17271

I was able to reproduce a 200 response when using an incorrect DB_HOST in my wp-config. Incorrect DB_NAME, DB_USER and DB_PASSWORD properly resulted in code 500.

#2 @sabernhardt
2 years ago

  • Version trunk deleted

The same happened with my 5.8 and 5.9 installations, so this should not be new to trunk.

#3 @rochow
17 months ago

Had a website with "can't establish a connection" error message. Weird because some pages work. Checked everything and all good.

Turns out the error page still returns header 200 (!!!) so it fell into the cache, and a random intermittent issue turned into however many hours of downtime.

Such an easy fix and it's best practice, header 200 is only when things are okay.

#4 @sabernhardt
17 months ago

In my case with the faulty DB_HOST, headers apparently are sent before the conditional statement that assigns the response error code.

Note: See TracTickets for help on using tickets.