re http status codes part 1 - 3

8/14/2019 RE HTTP Status Codes Part 1 - 3

1/11

More on HTTP error code troubleshootingPart 1:What each series of HTTP error status codes means

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

Part 1: What each series of HTTP error statuscodes 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 theWeb 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 clientissues 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 rareoccurrence 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 thebrowser 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 aparticular resource has been permanently moved and that all future calls to the resource should be directed to aspecific URL.

400 Series codes

Status codes in the 400 range are considered to be client error codes. These kinds of error codes are oftensecurity 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.
http://searchnetworking.techtarget.com/tip/0,289483,sid7_gci1337654,00.htmlhttp://searchnetworking.techtarget.com/tip/0,289483,sid7_gci1339228,00.htmlhttp://searchnetworking.techtarget.com/tip/0,289483,sid7_gci1340562,00.htmlhttp://searchnetworking.techtarget.com/tip/0,289483,sid7_gci1337654,00.htmlhttp://searchnetworking.techtarget.com/tip/0,289483,sid7_gci1339228,00.htmlhttp://searchnetworking.techtarget.com/tip/0,289483,sid7_gci1340562,00.html


2/11

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 sideerror, 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 orwas renamed.

500 Series codes

500 level status codes represent server errors. For example, if a Web server times out, it will produce a 504error. Often, though, a 500-level error does not represent a problem with a server but rather with the Webapplication 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 servererror. 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 howyou 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 anHTTP 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 helpfulin 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 ResourceKit 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.
http://searchnetworking.techtarget.com/tip/0,289483,sid7_gci1337654,00.htmlhttp://www.microsoft.com/downloads/details.aspx?FamilyID=56fc92ee-a71a-4c73-b628-ade629c89499&DisplayLang=enhttp://www.microsoft.com/downloads/details.aspx?FamilyID=56fc92ee-a71a-4c73-b628-ade629c89499&DisplayLang=enhttp://searchnetworking.techtarget.com/tip/0,289483,sid7_gci1337654,00.htmlhttp://www.microsoft.com/downloads/details.aspx?FamilyID=56fc92ee-a71a-4c73-b628-ade629c89499&DisplayLang=enhttp://www.microsoft.com/downloads/details.aspx?FamilyID=56fc92ee-a71a-4c73-b628-ade629c89499&DisplayLang=en


3/11

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 diagnoseon 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 enterwww.brienposey.cominto the HOST field and /kb/windows_xp_firewall.asp into the path field.
http://www.brienposey.com/kb/windows_xp_firewall.asphttp://www.brienposey.com/http://www.brienposey.com/http://www.brienposey.com/kb/windows_xp_firewall.asphttp://www.brienposey.com/


4/11

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 specifiedsite. 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 seethe 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 Outputwindow.

Figure B

The results are displayed in the Log Output window.


5/11


6/11

Conclusion

In this article, I have shown you how to use the WFetch tool to get a better look at the HTTP connection. In Part3, 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 withan 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 becauseMicrosoft 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 anerror 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.


7/11


8/11

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 errormessage.

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 witha message of my own. Many other sites use the same technique.

Figure B

Some websites use custom friendly errors.
http://www.brienposey.com/http://www.brienposey.com/


9/11


10/11

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 displaysthe 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 actuallybe 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 codeonto the page that you are troubleshooting:

system.webcustom 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 andIIS. 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,


11/11

Relevant Technologies and other technology companies. You can visit Brien's personal website at

http://www.brienposey.com/ www.brienposey.com
http://www.brienposey.com/http://www.brienposey.com/http://www.brienposey.com/

re http status codes part 1 - 3

Documents