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.
Click the image for a larger view.
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.
Click the image for a larger view.
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.
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 www.brienposey.com.
