Make WordPress Core

Opened 13 years ago

Closed 13 years ago

#17271 closed defect (bug) (worksforme)

WordPress returns a status code 200 when it can't connect to the database

Reported by: petemall's profile PeteMall Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Database Keywords: needs-patch
Focuses: Cc:


We should return 500 for DB creds and 503 for DB overloaded.

Change History (8)

#1 @PeteMall
13 years ago

  • Component changed from General to Database

#2 @nacin
13 years ago

I see status_header( 500 ); in dead_db().

#3 @dd32
13 years ago

I see status_header( 500 ); in dead_db().

Without looking at it, I suspect that'll be overridden by wp_die() further down the stack handling that. That being said, I don't expect it'll be a 200 code.. probably a generic 500 unless it's specified otherwise.

#4 @nacin
13 years ago

There's no wp_die() there, it's just <h1>Error establishing a database connection</h1>.

wp_die() is indeed 500 by default.

#5 @solarissmoke
13 years ago

I get a 500 response with bad credentials:

Date: Sat, 30 Apr 2011 09:04:53 GMT
Server: Apache/2.2.14 PHP/5.3.1
X-Powered-By: PHP/5.3.1
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified: Sat, 30 Apr 2011 09:04:53 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Content-Length: 1965
Connection: close
Content-Type: text/html; charset=utf-8

500 Internal Server Error

#6 @technosailor
13 years ago

I can confirm 500 on overloaded too but looking at the HTTP RFC, the 504 is, in theory correct, but I don't think it's semantically correct for an overloaded database. I think 500 is more apropos.

This is also because proxy servers use 504s in the way they do. I think using 504 for a database would be confusing for systems people to diagnose and would not, in fact, help the user any.

That being said, is there precedent for using 504 that I'm not aware of?

#7 @chrisbliss18
13 years ago

  • Cc gaarai@… added

I also confirm a 500 response code when a database connection cannot be made.

I don't see any code in core that specifically handles overload conditions nor do I know how to force one. I'd love to know how to do that for testing purposes.

With regards to the status code to use on db overload, the way I read the RFC, it sounds like 503 is appropriate but that it isn't required in an overload condition. Thus, a generic 500 is perfectly acceptable.

RFC 2616 relevant section:

10.5.1 500 Internal Server Error

The server encountered an unexpected condition which prevented it from fulfilling the request.


10.5.4 503 Service Unavailable

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.

Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the connection.

10.5.5 504 Gateway Timeout

The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.

Note: Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.

#8 @nacin
13 years ago

  • Milestone 3.2 deleted
  • Resolution set to worksforme
  • Status changed from new to closed

500 seems appropriate. Closing pending more feedback from Pete.

Note: See TracTickets for help on using tickets.