In my experience, HTTP errors fall into three main categories: problems with the user's device, problems with the Web server, and connectivity problems. The real key to troubleshooting HTTP problems effectively is to figure out which of these categories the problem falls into. In this series of articles, I will show you how.
HTTP status codes
The key to understanding the problem at hand is to know a little bit about HTTP status codes. Any time a client issues an HTTP request to a Web server, the server returns a response code. These response codes are organized into five categories.
100 Series codes
HTTP status codes ranging from 100 to 199 are informational codes. Running into these codes is a fairly rare occurrence for a couple of reasons. First, if a browser is attempting to access a website and these codes are returned, they are usually not displayed onscreen. They are simply internal codes for the browser's reference. The other reason these types of codes are fairly rare is that the original HTTP specification did not allow status codes in this range. As such, they are still not widely used.
200 Series codes
Status codes ranging from 200 to 299 are success codes. Again, you will probably never see these codes displayed on screen during a normal Web surfing session. Instead, these codes are used internally by the browser as a way of confirming the success and the current status of a request. Although these codes are not normally displayed, there are troubleshooting tools available that can read them, and like most other HTTP status codes, they can be invaluable in the diagnostic process.
300 Series codes
Status codes in the 300 to 399 range are redirection codes. Essentially, they tell the Web browser that some other action must be performed in order to fulfill the request. Depending on the nature of this action, it may be performed automatically, or it may require additional user input. For example, status code 301 indicates that a particular resource has been permanently moved and that all future calls to the resource should be directed to a specific URL.
400 Series codes
Status codes in the 400 range are considered to be client error codes. These kinds of error codes are often security related. For example, if a client attempts to access a resource that it is not authorized to access, the server will return a status code of 401. Similarly, if the client attempts to access an unauthorized resource, and the client's authentication status makes no difference to the situation, then the server may return a status code of 403, indicating that access to the resource is forbidden.
400 level error codes can also be returned if the request is malformed or if the client times out. The one 400-level code that is often misleading, though, is 404. Although this code is technically classified as a client side error, it can actually represent an error on either the client or on the server. The error simply indicates that the requested resource was not found. When this error occurs on the client side, it is often an indication of network connectivity problems. At other times, the error may occur because a resource was removed from the server or was renamed.
500 Series codes
500 level status codes represent server errors. For example, if a Web server times out, it will produce a 504 error. Often, though, a 500-level error does not represent a problem with a server but rather with the Web application that is running on the server. For example, my own personal website is coded in ASP, which dynamically generates HTML pages. During the debugging process, there were many times when buggy code caused my Web server to return HTTP status code 500, which is a generic code indicating an internal server error. This code simply means that something went wrong, and HTTP does not know how to deal with it.
As you can see, the individual HTTP error codes offer a lot of clues as to the cause of the problem. Even so, sometimes you can't fix the problem until you can gather more information. Fortunately, there are some free troubleshooting tools available that can help you to do just that. In Part 2 of this article, I will show you how you can use tools to help in the troubleshooting process.
|Brien M. Posey|
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
This was first published in November 2008