[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 rmccue):

 Replying to [comment:5 spacedmonkey]:
 > In [https://core.trac.wordpress.org/attachment/ticket/45933/45933.diff
 45933.diff] I had a first pass at handling REST API requests. However, it
 proved much much harder than I thought to handle REST requests than I
 thought. It is extremely hard to workout the request is meant to be REST
 API. This patch add `is_doing_rest`, that tries it's best to guess if the
 current request.

 The `REST_REQUEST` constant is built to answer the question of "is the
 current top-level request a REST API request?".

 The main thing is that knowing whether the current request is a REST
 request or not is mostly irrelevant, because the REST API is re-entrant.
 Specifically, REST requests can be dispatched and handled on page loads
 outside of REST API URLs.

 If I do `rest_do_request()` inside my header template, is the whole
 request a REST request? Is the request a REST request while
 `rest_do_request()` is running? Is the answer different inside embedded
 requests fired in the server?

 Generally speaking, we want people to avoid asking "is the parent code of
 the current code running in a REST API request?" because this introduces
 disparity between how WordPress operates for every other request and how
 it operates for the API. This means you'll inevitably end up with code
 that doesn't fit with an API-first mentality. Avoiding a way to detect
 this helps to shape behaviour to avoid this.

 > One of the biggest problems I had when testing this, was the fact that
 `rest_api_loaded` calls `die` instead of `exit` means that, the shutdown
 handler were never called.

 `die` is an alias of `exit` in PHP, they both fire shutdown hooks, and
 they both generate a [https://3v4l.org/DOuhc/vld#output EXIT opcode], so
 they are equivalent in every way. It's just a stylistic choice as to which
 to use, not a behavioural one. I'm not sure how you tested this to see
 disparity between the two.

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