Data Centers

Troubleshoot IIS connections with Wfetch

If you're having problems getting a particular workstation to connect to your Web site, it might not be the workstation's fault. You can use Wfetch to see if there's a problem on your IIS server. Brien Posey explains how Wfetch works.


As reliable as Web browsers and Web servers have become over the last few years, the reality is that there are times when a client’s connection to a Web server simply may not work correctly. If only one client is having a problem connecting to your Web site but other clients aren’t displaying similar problems, you may be inclined to dismiss the problem as being a client problem rather than a server problem.

What if that client can connect to other Web sites but not to yours? Such a situation points more toward a Web server problem than a client problem. So what do you do when you see contradictory symptoms and there are no clear answers? One possible way of solving the problem is to use the Wfetch utility to troubleshoot possible Web server connection problems.

What is the Wfetch utility?
Wfetch is a free utility provided by Microsoft to help you troubleshoot HTTP connection problems by allowing you to view data, such as the HTTP header, that isn’t usually displayed through a Web browser. You can download Wfetch from Microsoft’s Download Center.

Microsoft doesn’t officially support Wfetch. According to the Microsoft Web site, Wfetch is provided on an as-is basis and is completely unsupported. So don’t expect to get any help from Microsoft if you have problems with Wfetch.

Another thing that you need to know is that there are some serious security risks associated with using Wfetch. If you’re planning on using Wfetch to solve a problem, I recommend installing the Wfetch utility in a nonproduction environment initially. The Wfetch program isn't actually installed on a server; instead, it runs on a workstation. The problem is that Wfetch has a habit of installing things like passwords and certificates into the workstation’s registry. In some situations, Wfetch stores user passwords in clear text in the system’s registry.

Installing Wfetch
To install the Wfetch utility, double-click on the executable file that you downloaded. You'll then be asked which folder the installation program should extract the files into. Once the files have been extracted, three files will be placed into a folder called CodeSign in the location that you’ve specified. Open the CodeSign folder and run the Wfetch.exe file to run the Wfetch utility.

After double-clicking on the Wfetch.exe icon, you’ll see the Wfetch user interface, shown in Figure A. Wfetch’s interface isn’t very user-friendly.

Figure A
The Wfetch user interface isn’t very intuitive.


Along the top row of the Wfetch user interface, you’ll see four buttons. The button on the far left is the New Document button. This is the button you’ll use to preserve the results of your last test. You’ll also use this button if you want to run a second test after your first one but want to have the results of the second test placed in a different log file.

The next button (with a big X on it) is used to abort the current test. The third button has the Refresh icon on it; it's used to rerun the last request. The last button is the Log Cleanup button. Clicking this button will clear the current log screen. Be careful about clicking this button accidentally, because the utility doesn’t ask you if you’re sure that you want to erase the log; it just does it.

The next major section of the Wfetch interface is the section in which you specify the Web site that you want to analyze. The Verb field refers to the HTTP verb that you want to test. HTTP verbs are commonly used to perform various actions within an HTTP request. For example, if you associate the HEAD verb with a resource, then HTTP will return only the header information. If you associate the GET verb with the same resource, then HTTP will return the header and usually a message body as well.

The Host field is where you specify the host that you’re connecting to. Usually, the host is specified in the form of either an IP address or a URL.

The Port field allows you to pass the HTTP request through a specific port. If you leave the value set to Default, the request will be passed through TCP port 80.

The Ver field refers to the HTTP version used by the Web server. Your choices are 1.0 and 1.1. If you aren’t sure what version of HTTP is being used, try using version 1.1.

Finally, the Path field refers to a specific resource on a Web server. For example, if you were trying to troubleshoot a specific Web page or Web resource, you might specify that page or resource from within the Path field. The path is especially useful if you’re addressing an internal Web server by IP address and that server hosts several Web sites.

You could specify the IP address in the Host field and the Web site name in the Path field. For example, let’s say you want to test SharePoint Portal Server. To access the SharePoint default dashboard through Internet Explorer from your workstation, you’d enter the server name followed by the dashboard’s site name (bart.test.com—test in my example). To run the Wfetch utility against the dashboard site, you’d type bart.test.com into the Host field and type /test into the Path field, as shown in Figure B.

Figure B
The Path field is used to specify a Web site on an IIS server or a specific Web page within a Web site.


The next part of the Wfetch user interface is the Authentication section. This section allows you to control how the credentials that the Wfetch utility will use to access the host in question. For example, you might have noticed in Figure B that the default choice is Anonymous. If your Web site has anonymous authentication, you’d just leave the default settings.

Other available authentication types include Basic, NTLM, Kerberos, Digest, and Negotiate. If you choose to use any access method other than Anonymous, you must fill in the domain name, username, and password in the space provided beneath the authentication type. If you look at Figure B, you’ll notice that there’s a Save check box directly across from the Password field. If you select the Save option, your password will be saved in the registry in clear text, regardless of what authentication type you’re using. So make sure you heed my advice and check the registry when uninstalling the Wfetch utility.

The next area of the user interface is the Connection section. The Connection area allows you to configure how the Wfetch utility should attach to the host that you specified. The default options allow Wfetch to make a straight HTTP connection to the host. However, there is an option to pass the connection through a proxy server. If a proxy server, such as Microsoft's Proxy Server 2.0 or ISA Server, controls your Internet connection, you must select the Proxy check box and enter the port number used by the proxy server. By default, Proxy Server 2.0 uses port 80 while ISA Server uses port 8080.

Beneath the Connect field, you’ll see the Cipher field and Client Cert field. These fields exist because the Wfetch utility has the option of connection to a Web server using HTTP, HTTPS, PCT 1.0, SSL 2.0, SSL 3.0, or TLS 3.1. If you choose to use one of the secure protocols, you’ll have to select an encryption type from the Cipher drop-down list. Your choices include RC4, RC2, DES, and Triple DES.

The Client Cert field can be used only in conjunction with PCT 1.0, SSL 3.0, and TTLS 3.1 security. If you choose to use a certificate, you have several different options. The None option avoids using a certificate for the connection. The Certificate From IE option allows you to select one of the certificates that Internet Explorer is already configured to use. Should you choose this option, a dialog box will appear asking you to select the certificate. Once you’ve made your selection, a wizard will explain what to do next.

The Wfetch utility also gives you the option of using a valid certificate, an expired certificate, or an unrecognized certificate. Remember that you're testing a connection to a malfunctioning Web server, so there may very well be times when it’s appropriate to test the connection by using an expired or unrecognized certificate. The option of using a valid certificate presents the Web server with a Class 1 certificate that’s been signed by VeriSign. Although this certificate is intended to be valid, it’s hard coded into the utility and will therefore eventually expire.

You can check to make sure that the certificate is still valid by clicking on the arrow icon next to the Client Cert field. As you can see in Figure C, for example, my particular copy of Wfetch contains a certificate that expired in May of 2001. If your valid certificate has expired, then I recommend using an Internet Explorer-based certificate that is still valid.

Figure C
It’s possible that the certificate may have expired.


The only configuration-based section that remains is the Advanced Request section. This section allows you to do things like add headers, body, headers and body, or raw requests to the basic request. You can enable an advanced option simply by selecting it from the list. After choosing to make an advanced request, Wfetch gives you the chance to either type in the request or to copy code from an existing file. The advanced requests are entered into the text box found directly below the Advanced Request section.

Running a test
Now let’s run through the process of running a test so that you can see what the output looks like. I will show you a couple of problems to watch out for.

In Figure D, I am trying to run a Head test on my SharePoint Portal Server. Notice in the Authentication section that I have Anonymous access. SharePoint requires basic or NTLM authentication. So when I click the Go button to run the report, the Log Output section displays an HTTP/1.1 401 Access Denied message at the top of the text segment shown in blue. If a connection is failing due to security problems, this is what it will usually look like.

Figure D
This is what a security-related failure looks like.


The next thing that I want to show you is why the Path field is important. In Figure C, I was accessing the Test Web site on a server named Bart in the test.com domain. Normally, when accessing this Web site, I would type bart.test.com/test into Internet Explorer. However, in this case, I typed bart.test.com/test into the Host field rather than placing the /test parameter into the Path field where it belongs. Notice that the log section tells me that there is no such host. Obviously, the server and the corresponding Web site exist (and they are functional), but Wfetch reports that the host is unknown, as shown in Figure E, simply because I used an invalid method of addressing it.

Figure E
You’ll receive a host unknown error if you address the host incorrectly.


Now let’s look at a couple of successful tests. In Figure F, I’m using the HEAD verb to test my Web site. Notice in the figure that I’m using the Proxy option because I’m attaching to an external Web site.

Figure F
This is what a successful HEAD test looks like.


In Figure G, I’m doing the same test using the GET verb. In Figure F, the Wfetch tool returned information such as the Web server version and the date that the site was last modified. In Figure G, you can see that the same header information is displayed, but the tool also displays the HTML code found on the default Web page.

Figure G
The GET verb displays the header information and the Web site’s HTML code.


One last interesting thing to look at is the same test performed by using the TRACE verb. As you can see in Figure H, the TRACE verb allows you to watch the test as it passes from the proxy server to the Web and back.

Figure H
The TRACE test displays the actual connection process.


Fetch, Spot! Fetch!
The Wfetch utility is a useful tool for troubleshooting HTTP connection problems. The error reports it produces can help you figure out what’s wrong with your server. If you have problems understanding a particular error, you can use Microsoft’s Knowledge Base or Google to help you track down the error by searching for the error.

After you’ve used Wfetch to troubleshoot a problem, uninstall the utility immediately to prevent any security problems. Even after uninstalling the Wfetch utility, there’s a possibility that the registry keys containing the passwords could still exist. I recommend using the Registry Editor to check for the existence of this part of the registry and getting rid of the risky registry keys manually if necessary. The Wfetch registry keys are stored in HKEY_CURRENT_USER\Software\Wfetch. Keep in mind that if you’ve used Wfetch while logged on as multiple users, then this registry key may exist for each user you’ve logged on as.

Editor's Picks