0

What HTTP status should I return if my script throws an exception?

200 OK

or

500 Internal Server Error

Let's say user request parameters are correct but there is a bug in my script which causes an error message to appear instead of a proper response (XML, JSON or other format). What should be the HTTP status?

Richard Knop
  • 81,041
  • 149
  • 392
  • 552
  • I would say 404. I had the same question some time ago in my project, and I stayed with 404 after reading all the codes and their meanings. The cause of the exception is important. On sw error give 500, on invalid user input give 404 (invalid product id, etc). – Notinlist Jan 19 '12 at 17:29
  • 8
    It depends upon the exception and its meaning for the end-user! You should be much more precise to get a meaningful answer! – Basile Starynkevitch Jan 19 '12 at 17:29
  • 2
    @Notinlist So you would tell someone a resource doesn't exist if in fact you had simply made a programming error? Google will quickly stop displaying your URL in search results if you tell it the page doesn't exist :) A **404 Not Found** is only appropriate if the requested resource doesn't exist (and really only if it never existed). –  Jan 19 '12 at 17:31
  • Basile Starynkevitch: post your comment as an answer – Mchl Jan 19 '12 at 17:32
  • 1
    @Mchl: It's not a complete answer, so it's correct to leave a comment instead. – Dietrich Epp Jan 19 '12 at 17:33
  • Dietrich Epp: It's good enough for me to want to upvote it :) – Mchl Jan 19 '12 at 17:35
  • @rdlowrey: I agree with you on the 404 error. When I return a 404, I expect the user/consumer to never call the API ever again. If that is what I want, 404 is the appropriate code. In other cases, one should stay away from it. – Ayush Jan 19 '12 at 17:47
  • @xbonez - If you don't expect them to ever call it again (and it did previously exist), consider using `410 Gone`. `404` doesn't really convey any permanence; perhaps the target resource would exist in the future? – Rob Hruska Jan 19 '12 at 17:50
  • 1
    404 is only appropriate if the user asked for something that doesn't exist. If the user just gave you bad input, I think 400 (bad request) is more appropriate. – Ken Kinder Jan 19 '12 at 18:00

3 Answers3

9

500 Internal Server Error is the correct status if the error can't be fixed by the client changing their request.

Use any of the 4XX statuses if the client might be able to fix their request to avoid the error (or 404 if the resource wasn't found).

200 OK is not the appropriate status in almost any error situation, because then the client thinks things are running normally (which they are not) and may continue to make the same error-causing requests.

Familiarize yourself with the available status codes in RFC2616 and find one that most appropriately fits the situation.

Rob Hruska
  • 118,520
  • 32
  • 167
  • 192
  • +1 for pointing out that 404 means "not found", not "generic web service error". – Kirk Strauser Jan 19 '12 at 17:35
  • Other 5xx codes exist. For example, you could return 503 if you run out of database connections. – Dietrich Epp Jan 19 '12 at 17:43
  • @DietrichEpp - Definitely. It's tough to address all of the possible situations without more information, hence the link to the RFC to help the OP make the decision. – Rob Hruska Jan 19 '12 at 17:44
  • @DietrichEpp - Also, 500 is still an okay code to use if there's an issue caused by, e.g., no database connections. Generally, all 5XX statuses should be handled the same by clients. – Rob Hruska Jan 19 '12 at 17:47
3

It depends on why the exception is thrown since they can be used for almost any error. If it's thrown because some id in the URI is not found in the database I'd say 404. On the other hand if it's because the database is down I would throw a 500. If an exception is thrown but the resulting page would still be useful to the user I would say return 200.

Justin Lucas
  • 2,301
  • 14
  • 22
  • 1
    I would argue that if an exception is thrown, it should still be a 500 error, but the body of the response can still contain the useful content. – cdeszaq Jan 19 '12 at 17:33
  • @cdeszaq this might be useful to someone visually inspecting an error response but many HTTP clients will not read the response body if a 500 status code is provided, so the client will not necessarily be able to adjust its behaviour according to the cause of the error. This is why WCF exceptions can be returned as 200 with an error-type response. – tomfumb Jan 19 '12 at 17:41
  • @cdeszaq In most cases I would agree with you but I still argue that it depends. The HTTP status code is for the client's (web user/search engine bot) consumption. So lets say you throw an exception because you want to log some error but you're still confident that the body of the response will not be affected. The client should still be able to assume that the page is ok (which it should use the status code to check). This would avoid Google from deleting a page from the index because your analytics system broke. – Justin Lucas Jan 19 '12 at 17:45
  • I was assuming an unrecoverable exception, not an expected one, but I agree with you on handling expected ones. – cdeszaq Jan 19 '12 at 17:50
0

Review the Status Code Definitions. 500 or 400 should do for general issues, however, the more detailed you can be then the more useful the returned status will be.

Robert
  • 8,717
  • 2
  • 27
  • 34
  • By the time you get to PHP throwing an exception, I would say you have passed the point of a legitimate use for a `400`. The web server should catch anything that constitutes a `Bad Request` and PHP won't even get invoked. Anything that throws an exception is *probably* a `5xx` error - as it is server side. There are obviously cases where this is not true, like authenticating an requesting invalid resources, but these have their own codes (`401`, `403`, `404`) and do not constitute a `400 Bad Request` – DaveRandom Jan 19 '12 at 17:33
  • 1
    @DaveRandom - "The web server should catch anything that constitutes a Bad Request and PHP won't even get invoked."* - not necessarily. You could have been expecting a specifically formatted request body, but received a malformed one, and that would be worthy of a `400 Bad Request` (and the server wouldn't take care of that). The status is particularly useful for APIs (rather than regular ol' web page requests - although it can still be useful for those, too). – Rob Hruska Jan 19 '12 at 17:39
  • @RobHruska - Thanks for clarifying what I should have initially expanded on within my answer. Now if only my employer's proxy liked SO and could load it as expected without timing out then I would not be 2 hours behind. – Robert Jan 19 '12 at 19:46