[wp-trac] [WordPress Trac] #45933: WSODs protection returns incorrect content type

[WordPress Trac]

#45933: WSODs protection returns incorrect content type
----------------------------------+------------------------------
 Reporter:  spacedmonkey          |       Owner:  (none)
     Type:  defect (bug)          |      Status:  new
 Priority:  normal                |   Milestone:  Awaiting Review
Component:  Bootstrap/Load        |     Version:  trunk
 Severity:  normal                |  Resolution:
 Keywords:  servehappy has-patch  |     Focuses:  multisite
----------------------------------+------------------------------

Comment (by spacedmonkey):

 Thanks @rmccue for getting back to me on this one.

 The issue here is, that the `REST_REQUEST` is setup until `parse_request`
 filter, this is far late to help for this use case.  Take the following
 use case as example.

 1. User requests posts from rest api - http://build.wordpress-develop.test
 /wp-json/wp/v2/posts
 2. Plugin activated by users, is hooked in at `plugins_loaded`
 3. Plugin has fatal error.
 4. Users is returned error message from shutdown controller.

 As `plugins_loaded` is before `parse_request`, `REST_REQUEST` isn't setup
 and we can't work out if request was meant to be a REST API request and a
 html error is displayed. `doing_rest` should only be true if the url
 requested `wp-json/wp/v2/posts`. So the logic of it should be more like
 this.

 {{{#!php
 function wp_doing_rest(){
      global $wp;
      if ( isset( $wp ) && $wp->query_vars['rest_route'] ) {
          return true;
      }
      return false.
 }
 }}}

 But this isn't possible as this `$wp->add_query_var( 'rest_route' );`
 isn't called until init.

 Not sure how I saw different behaviours on die / exit change, maybe that
 wasn't the reason why I saw a different and something else was at play
 here. I don't know.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45933#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform