Deciding which HTTP status code to use in a HTTP response

When we are in the business of creating web applications, we are always crafting HTTP responses.

A HTTP communication session is initated with a HTTP request from the client and is ended with a HTTP response from the server. In order for a HTTP communication session to take place successfully, the server must be reachable via an IP Address and a port number.

However, a successful HTTP communication session does not imply that the client always get what it wants from the server. Within the HTTP response, the server tells the client whether or not the HTTP request is plausible to fulfill via HTTP status codes.

This is a discussion of some of the status codes that I use at the HTTP server end, in an environment where most of my HTTP clients are robotic in nature.

200 OK

By default, a 200 OK is always inserted into HTTP responses by the programming languages that I use. This particular status code tells the client is that the server was able to fulfill the HTTP request and that the requested content is available right after the header section of the HTTP response. For cases like this, I would write the content directly to the server without explicitly setting the status code.

301 Moved Permanently

When I have old urls that are still being referenced to, I will use a 301 Moved Permanently to tell the client that the content that it had requested for had been relocated permanently. This status code will prompt client to look for the HTTP Location header for the new url. With such information, the client could remember the new urls to use in order to consume the content that it needs.

302 Found

While 301 allows me to tell my the HTTP client that a resource had been moved permanently to a new url location, 302 Found lets me redirect clients to another url location temporaily. This status code is commonly used in codes that restrict client accesses to private resources.

In the event when I am not able to verify a client with my server session data, I will retun a HTTP response with a 302 Found status code together with a HTTP Location header with the url to the server end that can authenticate the client.

When the server end authenticates the client, I will redirect the client back to the url to the private resource that he/she had tried to access before logging in. This time round, a HTTP response with a 302 Found status together with a HTTP Location header with the url to the private resource.

400 Bad Request

Did the HTTP request contain all the variables that is needed to retrieve the corresponding content? No? Then a HTTP response with a 400 Bad Request as the status code is what I will send back to the client.

403 Forbidden

This is for indicating to the client that it is not allowed to access a particular resource. For instance, if the client fails to provide a valid username and password combination, I will return a HTTP response with a 403 Forbidden as the status code.

404 Not Found

The client asks for something that is not there on the server. For example, the client may ask for a report for a future date, which is not yet available. This is the kind of situation where I will send a HTTP response with a 404 Not Found as the status code.

500 Internal Server Error

Something unexpected happens during processing at the server side? A HTTP response with a 500 Internal Server Error is what I will reply back to the client. Although this status code seems to be a convenient one for returning back to the client for whatever exceptions that I catch in my server script, I will try to minimize the cases in which I return this status code. Such cases should be logged and analysed so as to increase the robustness of the HTTP server.

Closing Remarks

The choice of which HTTP status codes to use is more evident in coding web applications that serves HTTP clients that are robotic in nature. One example could be that command-line application that is scheduled to harvest information from the private HTTP server to make reports available for the public.

For web applications that server HTTP requests from web browsers, I usually find my choice of HTTP status code reduced to the set of 200, 301 and 302. This is because we can be sure that browsers render the content portion of HTTP responses marked with a 200 OK. With that, even when we encounter errors, we still have the chance to keep the user on our website.

For instance, if we cannot find a resource that the browser had indicated in a HTTP request, we could return a HTTP response with a 200 OK that tells the user that what she was looking for could not be found and provide her some suggestions that are related to her previous request. Or perhaps when she had mistyped her password, to allow her another chance to fill in her login credentials again, or to prompt her the url to retrieve her forgotten password.

Finally, this post covers only a subset of the full list of HTTP status codes. There maybe other status codes that are more appropriate for your use.

Related posts

About Clivant

Clivant a.k.a Chai Heng enjoys composing software and building systems to serve people. He owns techcoil.com and hopes that whatever he had written and built so far had benefited people. All views expressed belongs to him and are not representative of the company that he works/worked for.