More on HTTP error code troubleshooting

Part 1: What each series of HTTP error status codes means

Part 2: How to use WFetch to troubleshoot HTTP error codes
Part 3: Disabling friendly error messages to find root problems

Part 1: What each series of HTTP error status

codes means
If you have ever had to troubleshoot an HTTP error code, you know how frustrating the process can be.
Oftentimes, these cryptic codes can have multiple meanings and can leave you scratching your head. 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.

Conclusion

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.

HTTP error code troubleshooting, Part 2: How to

use IIS tool WFetch
In HTTP error code troubleshooting, Part 1, I explained that you could get a good idea of what was causing an
HTTP error by looking at the error code. Sometimes looking at the error code alone isn't enough, though. In this
article, I want to continue the discussion by showing you how to use a tool called WFetch to troubleshoot HTTP
errors.

What is WFetch?
In order to understand what WFetch is, you have to understand that when an HTTP error occurs, Internet
Explorer does not display everything that it knows about the error, instead displaying what is known in
Microsoft circles as a "friendly error message." Even though the friendly error message may not be that helpful
in resolving the problem, there is lots of valuable information embedded in the HTTP request and response
packets.

WFetch is a part of the Internet Information Services (IIS) 6.0 Resource Kit. It is designed to help you extract
valuable troubleshooting information from the HTTP packet headers. You can download the IIS 6.0 Resource
Kit at Microsoft's Download Center.

Using WFetch
After you download and install the IIS 6.0 Resource Kit, you can access WFetch by clicking on the Windows
Start button and selecting the All Programs | IIS Resources | WFetch | WFetch command. When WFetch starts,
you will see a screen similar to the one that is shown in Figure A.
 Figure A
This is what the WFetch console looks like.

At a minimum, there are two pieces of information that you must enter into WFetch. First, you must populate
the HOST field. This field is set to LOCALHOST by default, but you should replace the default entry with the
URL that you are having problems with.

The other thing you have to do is populate the PATH field. This is the specific page that you want to diagnose
on the website that you are having problems with. For example, suppose that I were having problems with the
following page on my website: http://www.brienposey.com/kb/windows_xp_firewall.asp If that were the case, I
would enter www.brienposey.com into the HOST field and /kb/windows_xp_firewall.asp into the path field.
Of course, these are not the only options that you can set. You also have the option of specifying a different
HTTP verb, although GET usually works fine.

It is also worth mentioning that WFetch is configured by default to use anonymous authentication. If you are
trying to troubleshoot a website that requires authentication, you do have the option of providing a set of
authentication credentials. In fact, you can even specify that you want to use Basic, NTLM, Kerberos, Digest, or
Negotiate authentication.

Some versions of WFetch allow you to save the password that you are using for authenticating into the specified
site. If you have such a version, you need to be aware that if you decide to save the password, it will be stored in
clear text in the Windows registry at HKEY_CURRENT_USER\Software\WFetch. That being the case, I do not
recommend saving passwords.

One last thing that I want to point out is the Connect option, found in the console's Connection section. By
default, WFetch is configured to connect to a site using the HTTP protocol, but you do have some other options
as well. You can connect using HTTPS, PCT 1.0, or one of several versions of SSL or TLS.

Once you have entered the various parameters for your test, just click the Go button. When you do, you will see
the connection request and the server's response displayed in the Log Output section. You can see an example
of this in Figure B. Notice in the figure that the HTTP status code is displayed just above the Log Output
window.

Figure B
The results are displayed in the Log Output window.
Conclusion
In this article, I have shown you how to use the WFetch tool to get a better look at the HTTP connection. In Part
3, I will conclude this series by showing you one last technique for getting more information about an HTTP
error message.

HTTP error code troubleshooting, Part 3: Disabling

IE friendly error messages
So far in this article series, I have shown you a few different methods for getting to the bottom of an HTTP
error message. In this article, I want to conclude the series by showing you one last technique for dealing with
an HTTP error message.

Friendly errors
One reason why HTTP errors are so hard to troubleshoot is that Microsoft likes to hide a lot of the details about
the error message from us. I don't think that this information is being obscured for security reasons or because
Microsoft wants to withhold information from us; rather, it seems to be an effort to help people who are less
computer literate.

For example, one of the most common types of HTTP error message is the 404 error. To see what a 404 error
looks like, just go to your favorite website and enter an invalid URL. When you do, you will most likely see an
error message like the one that is displayed in Figure A.

Figure A
A 404 error is one of the most common types of HTTP errors.
As you can see in the figure, the fine print tells you that a 404 error has occurred, and it even tells you that the
error occurred because a file was not found. That's really about the only technical information we get, though.
The rest of the information on the page is there to tell novices how they might be able to get around the error
message.

Sometimes friendly error messages are dressed up a bit. For example, if you go to my website
(www.brienposey.com) and enter an invalid URL, you will see a page similar to the one shown in Figure B.
This is still considered a friendly error message. I have simply replaced Microsoft's generic error message with
a message of my own. Many other sites use the same technique.

Figure B
Some websites use custom friendly errors.
Whether a site uses a generic or custom friendly error message, you probably won't get a lot of technical
information about the problem from it. Fortunately, there is something you can do. Internet Explorer contains an
option that you can use to display the real error message instead of the friendly error message.

The exact method of doing this varies from one version of Internet Explorer to another, but here's how it's done
in Internet Explorer 7. Choose the Internet Options command from the Tools menu. When Windows displays
the Internet Options properties sheet, go to the properties sheet's Advanced tab. Finally, deselect the Show
Friendly HTTP Error Messages check box, located in the Browsing section. When you're done, click OK.

When disabling friendly error messages does nothing

After you disable the friendly HTTP error messages, you may find that the error pages still look the same. A
couple of things can cause this. For starters, if you are looking at a 404 error, the error message is typically
going to look the same because there really isn't anything to report except that the requested file was not found.

Another reason why an error may not look any different than before is that Internet Explorer may not actually
be making a connection to the website. For example, if your Internet connection is down, you will get a 404
error message whether the page you requested actually exists or not.

Another common reason for continuing to receive generic error messages is that the requested page may be
cached. Try emptying the browser cache and then requesting the page again.

If you own the website that is having problems and that website is running on IIS 7, try accessing the site
locally, directly from the server console. Doing so will ensure that you receive a detailed error message. If a site
is coded using ASP.net, you may end up receiving ASP's custom errors instead of the detailed messages that
you are interested in. If this happens, you can fix the problem by temporarily embedding the following code
onto the page that you are troubleshooting:

‹system.web›
‹custom errors mode="Off" /›
‹/system.web›

Conclusion
In this article, I have explained how you can disable Internet Explorer's friendly error messages. I then went on
to talk about a couple of reasons why you may continue to see friendly error messages even when you have
disabled friendly error messages in your browser.

About the author:

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
http://www.brienposey.com/www.brienposey.com