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

[WordPress Trac]

#45933: WSODs protection returns incorrect content type for JSON Requests
--------------------------------------------------+------------------------
 Reporter:  spacedmonkey                          |       Owner:  flixos90
     Type:  defect (bug)                          |      Status:  reviewing
 Priority:  normal                                |   Milestone:  5.1
Component:  Bootstrap/Load                        |     Version:  trunk
 Severity:  normal                                |  Resolution:
 Keywords:  servehappy needs-patch needs-testing  |     Focuses:  multisite
--------------------------------------------------+------------------------

Comment (by spacedmonkey):

 Thanks for the feedback @flixos90

 I have changed some of the stuff in your request but not all.

 - There is a lack of docs as the function is still being written, docs are
 a final stage when design is locked down, not in the patch stage.
 - With `_wp_die_process_input` the idea is create a formatted array, that
 can be used by `_json_wp_die_handler`.  This format is defined
 [https://github.com/WordPress/WordPress/blob/47d32decd6668b3ccf100acc8a40aa0a9fc35003
 /wp-includes/rest-api/class-wp-rest-server.php#L150-L181 here] and looks
 something like this.

 {{{#!php
 {
     code: "rest_no_route",
     message: "No route was found matching the URL and request method",
     data: {
        status: 404
     }
 }
 }}}
 Going forward, I would like xml handler (see #46026) to be in this same
 structure but just formatted as xml. So
 {{{#!php
 <error>
     <code>rest_no_route</code>
     <message>No route was found matching the URL and request
 method</message>
     <data>
        <status>404</status>
     </data>
 </error>
 }}}

 Keeping this structure is important, as it means that, if we copy the
 existing structure from the rest api, then this error message should work
 with existing code (in gutenberg) that handles REST API errors. It is
 important to have a defined error state that doesn't change it's format,
 as monitor tools and error handling will depend on this exact formatting.

 I know the format of the data isn't perfect, I don't love the data array
 for status and title, but it makes it possible for `WP_Error` to pass a
 title as well as status, which is an improvement.

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