-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect use of 503 status code #11512
Comments
Your suggestion seems perfectly valid to me, I didn't even know it was not 500. Would you mind to prepare a PR maybe? https://github.com/magento/magento2/blob/2.2-develop/pub/errors/processor.php#L218 It can be done directly via GitHub Web UI. |
dirty UI change implemented |
Hola @magento-engcom-team; Can you explain more behind the "non-issue" tag? As well as why this is closed. I'd argue this is an issue, as it makes it difficult to determine when the application is failing due to load (a fine, transient condition) and critically broken though the status code analysis. |
Hi @andrewhowdencom, |
Hi @andrewhowdencom. Thank you for your report. The fix will be available with the upcoming 2.2.4 release. |
Hi @andrewhowdencom. Thank you for your report. The fix will be available with the upcoming 2.3.0 release. |
Hi @andrewhowdencom. Thank you for your report. The fix will be available with the upcoming 2.1.15 release. |
More generally, Magento appears to use the "503 (service unavailable)" status code when an "unexpected error" happens. This ranges, but a good example of such an event is anything that generates the "report" format pages.
The problem is, this status code is generally reserved for cases in which the server is suffering a temporary problem[1][2]. When the server is in an error case, I would have expected something such as a 500 (internal server error) to be expressed, clearly indicating an "abnormal" event, or one that is not an expected failure mode.
This has implications for monitoring. When setting up alerting rules, it's unclear how to express that a problem is temporary in nature. For example, if during a period of high traffic there are several 503s, this does not warrant immediate resolution. However, if there is a spike in 503s as a result of an SQL constraint issue, this requires immediate attention, and will not self-resolve.
I would suggest modifying the report page to return a 500, rather than a 503. Additionally, some guidelines as to what status code was used when would be useful.
[1] - https://stackoverflow.com/questions/2786595/what-is-the-correct-http-status-code-to-send-when-a-site-is-down-for-maintenance
[2] - https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
The text was updated successfully, but these errors were encountered: