[wp-trac] [WordPress Trac] #63836: Use more appropriate HTTP status codes for wp_die

[WordPress Trac]

#63836: Use more appropriate HTTP status codes for wp_die
--------------------------+-----------------------------
 Reporter:  kkmuffme      |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:
 Severity:  trivial       |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 By default wp_die uses HTTP status 500.
 This is also the status PHP uses for fatal errors.
 The docs state:
 https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/500
 >**If you're a visitor seeing 500 errors on a web page, these issues
 require investigation by server owners or administrators**
 There are many possible causes of 500 errors, including: improper server
 configuration, out-of-memory (OOM) issues, unhandled exceptions, improper
 file permissions, or other complex factors. Server administrators may
 proactively log occurrences of server error responses, like the 500 status
 code, with details about the initiating requests to improve the stability
 of a service in the future.

 Looking at e.g.
 `wp_die( __( 'You attempted to edit an item that does not exist. Perhaps
 it was deleted?' ) );`

 The 500 status does not really fit the description. In fact in this 1
 file, there are lots of similar cases that all should use a more
 appropriate HTTP status:

 https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-
 admin/post.php#L127 => 404
 https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-
 admin/post.php#L131 => 404 or 400
 https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-
 admin/post.php#L135 => 403
 https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-
 admin/post.php#L139 => 403
 https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-
 admin/post.php#L143 => 404 or 410
 and a lot more

 While this seems a small, trivial issue at first the impact is quite
 annoying:
 - lots of NEL reports (if enabled) with status 500, making it hard to
 distinguish between actual, legit server issues and just WP using the
 wrong HTTP status
 - unnecessary extra work for server admins, since they see the 500 in
 their logs, but the PHP fatal is logged to another team or even if they
 have access, multiple teams now need to check an error that isn't an error
 at all - bc it's just a 404 and not a server misconfiguration
 - because 500 status usually has way more logging (and way less caching)
 involved, minimally more server resources are required

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63836>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform