[wp-trac] [WordPress Trac] #11286: Normal User Input Causes Status 500

[WordPress Trac]

#11286: Normal User Input Causes Status 500
------------------------------+----------------------
 Reporter:  miqrogroove       |       Owner:  ocean90
     Type:  defect (bug)      |      Status:  closed
 Priority:  normal            |   Milestone:  4.1
Component:  Comments          |     Version:  2.8.4
 Severity:  normal            |  Resolution:  fixed
 Keywords:  has-patch commit  |     Focuses:
------------------------------+----------------------

Comment (by westonruter):

 I just noticed that a bunch of error responses are returning 200 status
 code:

 * `comment_author_column_length`
 * `comment_author_email_column_length`
 * `comment_author_url_column_length`
 * `comment_content_column_length`
 * `require_name_email`
 * `require_valid_email`
 * `require_valid_comment`

 Replying to [comment:44 mackensen]:
 > * Validation errors: 200. I agree completely w/bpetty. This isn't a 4xx
 error: the request was understood and the client received a response.

 I don't think this is right. Sure the request was understood, but it was
 understood to be incorrect.

 Should they not be 400 (Bad Request)? The argument against 400 was this
 [comment:21 comment]:

 > The HTTP Specification says that 400 is for when "the request could not
 be understood by the server due to malformed syntax". So whilst this might
 be an appropriate response for invalid inputs (e.g. bad email address), I
 don't think it should be used in wp-includes/comment.php for duplicate
 comments and comment flooding. There 403 is more appropriate.

 The REST API sends 400 status code responses in
 `\WP_REST_Comments_Controller::create_item()` for these errors:

 * `rest_comment_exists`
 * `rest_invalid_comment_type`
 * `rest_comment_content_invalid`
 * `rest_comment_author_data_required`
 * `comment_author_column_length`
 * `comment_author_email_column_length`
 * `comment_author_url_column_length`
 * `comment_content_column_length`
 * `comment_flood`

 The exceptions are `comment_duplicate` which returns
 [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/409 409]
 (Conflict), and the generic DB error `rest_comment_failed_create` which
 returns with a 500 error code, as expected.

 For the length errors, a [https://developer.mozilla.org/en-
 US/docs/Web/HTTP/Status/413 413] (Payload Too Large) code may be more
 specific. Also, for comment flooding, what about the status
 [https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429 429] (Too
 Many Requests)? The REST API should perhaps be updated to use this instead
 of 400.

 All this to say, to align with the REST API the comment form submission
 errors should use 400+ error codes instead of 200. I'll open another
 ticket with a patch.

 I've opened #47393 with a patch to revise this.

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