Which HTTP status codes do you actually use when developing web applications?

Question

The HTTP/1.1 specification (RFC2616) defines a number of status codes that can be returned by HTTP server to signal certain conditions. Some of those codes can be utilized by web applications (and frameworks). Which of those codes are the most useful in practice in both classic and asynchronous (XHR) responses, in what situations you use each of them?

Which codes should be avoided, eg. should applications mess with the 5xx code range at all? What are your conventions when returning HTTP codes in REST web services? Do you ever use redirects other than 302?

Answer 1

Here are the most common response codes, from my experience:

The response codes in the 1xx-2xx range are typically handled automatically by the underlying webserver (i.e. Apache, IIS), so you don't need to worry about those.

Codes 301 and 302 are typically used for redirects, and 304 is used a lot when the client or proxy already contains a valid copy of the data and does not need a new version from the server (see the RFC for details on exactly how this works).

Code 400 is typically used to indicate that the client sent bad or unexpected data that caused a problem in the server.

Code 403 is for performing authentication, which is again usually handled somewhat automatically by the server configuration.

Code 404 is the error code for a page not found.

Code 500 indicates an error condition in the server that is not necessarily caused by data sent from the client. For example, database connection failures, programming errors, or other unhandled exceptions.

Code 502 is typically seen if you are proxying from a webserver (such as Apache) to an app server (such as Tomcat) in the backend, and the connection cannot be made to the app server.

For asynchronous calls (i.e. AJAX/JSON responses) it's usually safest to always return a 200 response. Even if there was an error in the server while processing the request, it's best to include the error in the JSON object and let the client deal with it that way. The reason being that not all web browsers allow access to the response body for non-200 response codes.

Answer 2

In Aida/Web framework we use just

• 200 Ok
• 302 Redirect
• 404 Not Found
• 500 Internal Server Error

Answer 3

The ones I'm using (that I could find with a quick grep 'Status:' anyway):

• 201: Sent whenever a form submission puts something significant into the database (forum post, user account, etc.)
• 304: HTTP caching. I've found this one is very hard to get right since it has to account for users changing display settings and so on. The best idea I've come up with for that is using a hash of the user's preferences as the ETag. It doesn't help that most browsers have unpredictable and inconsistent behaviour here...
• 400: Used for bad form submissions that fail some validation check.
• 403: Used whenever someone is somewhere they shouldn't be (though I try to avoid that by not displaying links to stuff the users shouldn't access).
• 404: Apart from the normal webserver ones I use these when the URL contains invalid ID numbers. I suppose it'd be a good idea to check in this case whether a higher valid ID exists and send a 410 instead...
• 500: I tend to put these in catch{ } blocks where the only option is to give up, to make sure something meaningful is sent to the browser.

I realise I could get away with simply letting the server send "200" for everything, but they save a lot of pain when users are seeing (or causing) errors and not telling you about them. I've already got functions to display access-denied messages and so on, so it's not much work to add these anyway.

Answer 4

I've had nightmares about the number 500.

Answer 5

I tend to use 405 Method Not Allowed when somebody tries to GET an URL that can only be POSTed. Anyone else does it the same way?

Answer 6

303 See Other is a must for PRG, which you should be using now if you aren't already.

Answer 7

500 Internal Server Error is returned in Aida/Web when your web application raise an exception. Because this is a Smalltalk application, an exception window is raised on the server (if you run it headfull) while the user got 500 and a short stack.

On the server you can then open a full debugger and try to solve the problem, while the server is continuing running of course. Another nice thing is that exception window with full stack is waiting for you until you come around.

Conclusion: 500 is a blessing, not a nightmare!

Answer 8

I basically use all of them, where appropriate. The spec itself defines each code and the circumstances in which they should be used.

When building a RESTful web application, I don't recommend picking-and-choosing status codes, and restrict oneself to a subset of the full range. That is, unless one's building a web application for a specific HTTP client - in which case one isn't really building a web application, one's building an application for that specific client.

At my firm, we have some Flex clients. They can't properly handle status codes other than 200, so we have them send a special parameter with their requests, which tells our servers to always send a 200, even when it's not the proper response.

Answer 9

418: I'm a teapot

From http://www.ietf.org/rfc/rfc2324.txt Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)

Answer 10

Don't forget about 503 - Service Unavailable. This one is essential for site downtime. Especially where Search Engines are concerned.

Say you're taking the site down for a few hours for maintenance or upgrade work. By directing all requests to a friendly page that returns a 503 code, it tells spiders to "try again later".

If you simply display a "Temporarily Down" page but still return 200 OK, the spider may index your error pages or, worse, replace existing indexing with this "new" content.

This could seriously impact your SEO rankings, especially if your a large, popular site.