WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#6076 closed defect (bug) (worksforme)

Incorrect use of HTTP status code 500

Reported by: runeh Owned by: westi
Milestone: Priority: normal
Severity: normal Version: 2.3.2
Component: General Keywords:
Focuses: Cc:

Description

When trying to log in using a wrong username or password, Wordpress issues an HTTP 500 status code, and the request body states that wrong credentials has been supplied. As I am sure you know, 500 means Internal Server Error. A more suitable status code to use would be 403 (Forbidden).

The 500 status code is also issued when submitting an empty username or password. I think 400 (Bad Request) would be a better fit. Both of these errors are made by the user, not the server, so it stands to reason that the status codes should be in the 400 range.

I also noted that a 500 status code is issued if a user is commenting to quickly (as an anti-spam measure). I'm not convinced that 500 is the correct status to use, however I'm unsure about which status fits best.

Fixing these issues will make Wordpress behave more semantically correct with regards to the HTTP protocol.

Change History (3)

comment:1 westi6 years ago

  • Keywords needs-patch added
  • Owner changed from anonymous to westi
  • Status changed from new to assigned

comment:2 guillep2k6 years ago

  • Cc guillep2k added

Personally, I don't think any status codes different from 200 would be correct, since at HTTP level you're actually delivering the requested page (i.e., the results of the user providing login credentials). 4xx error codes are (again according to my opinion) for HTTP errors (e.g., 400/Bad Request is for a malformed HTTP request, like invalid usage of headers) and not for application level errors. Using HTTP (transport) error codes to reflect application statuses seems to me like mixing design layers. Proxies and user agents act upon these errors and may choose not to show the user your provided HTTP response body but replace it for a body of their own.

Nevertheless, 500 is obviously wrong. 403 is meant to reflect the fact that access is forbidden, despite any credentials you may provide (so, 403 is semantically incorrect). The correct code should be 401, but that's for the HTTP protocol, not the Wordpress application. You know what happens if you send back a 401 status: the user agent (browser) will ask for credentials and attempt basic authentication. This is my point as why I think we're mixing layers if we pretend to use HTTP codes different from 200.

In my opinion, Wordpress shouldn't return anything except: 200 (pages served), 404 (custom page not found page) and 303 (to redirect to a permalink). See a good article about these codes at Wikipedia http://en.wikipedia.org/wiki/List_of_HTTP_status_codes.

comment:3 janbrasna5 years ago

  • Cc janbrasna added
  • Keywords needs-patch removed
  • Milestone 2.9 deleted
  • Resolution set to worksforme
  • Status changed from assigned to closed

Seems fixed as of 2.7-RC2, returns HTTP 200 OK.

Note: See TracTickets for help on using tickets.