[wp-trac] [WordPress Trac] #47393: Comment form submission with invalid fields incorrectly returns 200 OK response

[WordPress Trac]

#47393: Comment form submission with invalid fields incorrectly returns 200 OK
response
--------------------------+------------------------------
 Reporter:  westonruter   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Comments      |     Version:  4.1
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  rest-api
--------------------------+------------------------------

Comment (by TimothyBlynJacobs):

 > Code 400 signifies a malformed HTTP header that the server cannot
 process. I would never use this for form validation except where the
 payload is missing or cannot be parsed at all.

 This is no longer true.

 From the RFC: https://tools.ietf.org/html/rfc7231#section-6.5.1

    The 400 (Bad Request) status code indicates that the server cannot or
    will not process the request due to something that is perceived to be
    a client error (e.g., malformed request syntax, invalid request
    message framing, or deceptive request routing).

 Relevant SO discussion following that RFC:
 https://stackoverflow.com/q/16133923

 > From what I know of this, REST errors are conveyed within the API's
 response entity.

 This is partially correct. The error code, equivalent to
 `WP_Error::get_error_code()`, is returned in the response entity, but the
 equivalent status code, for instance `400` is also returned as the HTTP
 status.

 Taking a brief look at `wp_die` usages there are already cases of sending
 a `40x` response status code.

 {{{#!php
 wp_die( __( 'This site is no longer available.' ), '', array( 'response'
 => 410 ) );
 wp_die( __( 'A post ID mismatch has been detected.' ), __( 'Sorry, you are
 not allowed to edit this item.' ), 400 );
 }}}

 > Departing from those standards would not seem to be of much benefit,
 In an API context, this can be extremely helpful. A number of HTTP
 libraries, for instance Guzzle, offer to reject 40x or 50x response codes
 and treat it as an error. Additionally, it allows determining that a
 request failed without having to scrape the output.

 > Then why does the WordPress REST API use the 400 response code for
 invalid comment requests?

 One such difference is that the WordPress REST API is a REST API and
 returning a `200` status code for an error response is strongly
 discouraged.

 I guess the question is whether `wp-comment-post.php` would be seen as an
 HTTP API of some kind?

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