A Birdseye View of Publishing

Publishing is easily one of the most troublesome aspects of FrontPage for many users. When you publish a FrontPage Web site, you rely on not only your own machine being configured correctly, but you also rely on the machine to which you are publishing the Web site to be configured correctly. In addition to that, you have to contend with any machines that lie between you and the destination server. Quite simply, plenty can go wrong when you're publishing a Web site.

Where the Information Goes

When you request a page from your Web site on the Internet, you aren't sending and receiving information directly to and from the Web server your site is hosted on. Instead, you are sending and receiving information through many machines on the Internet. For example, I traced a browsing session between my machine and a Web server that I know to be just across town. The information being exchanged between my machine and that Web server went through 13 other machines on the Internet before it reached the remote Web server.

NOTE

If you are curious about how information is exchanged between computers on the Internet, read Special Edition Using TCP/IP.

Tracing Your Data

Each time information you transmit moves from one computer to another, it's called a hop. Microsoft Windows ships with a utility called tracert that will allow you to see how many hops there are between you and another computer on the Internet.

You can run tracert from a command window by running the command as follows:

 tracert www.mysite.com 

Change www.mysite.com to the URL that you want to trace. The output will show you each computer along the route between you and the site you enter as well as the amount of time it took for the round-trip between you and each computer along the route. Three time periods are listed for each hop, each one in milliseconds, because tracert sends three separate requests to each computer along the way and it times the round-trip for each. Here is sample output from running tracert from my computer to www.microsoft.com.

 Tracing route to www.microsoft.akadns.net [207.46.249.222] over a maximum of 30 hops:   1     3 ms     3 ms     3 ms  192.168.0.1   2    20 ms    20 ms    20 ms  66.140.45.254   3    20 ms    21 ms    20 ms  151.164.162.130   4    21 ms    19 ms    21 ms  151.164.1.143   5    19 ms    20 ms    20 ms  151.164.240.233   6    22 ms    19 ms    21 ms  151.164.240.82   7    54 ms    54 ms    52 ms  151.164.243.218   8    53 ms    54 ms    54 ms  151.164.242.70   9    53 ms    54 ms    55 ms  151.164.241.26  10    54 ms    55 ms    55 ms  151.164.89.194  11    53 ms    55 ms    54 ms  207.46.33.117  12    55 ms    55 ms    52 ms  207.46.34.22  13    53 ms    55 ms    54 ms  207.46.34.25  14   111 ms   111 ms   110 ms  207.46.33.61  15   110 ms   111 ms   110 ms  207.46.36.78  16   112 ms   112 ms   111 ms  207.46.155.13  17     *        *        *     Request timed out. 

Notice that after 16 hops, you see asterisks in place of the time value and a message that the request timed out. This happens when you hit a firewall, a special computer that is designed to prevent unauthorized access into a network. Most firewalls are configured not to respond to utilities such as tracert.

If you'd prefer to see a map of each hop in your request, you can purchase an application called Visual Trace from McAfee Security. Visual Trace is available from the McAfee Security Web site at http://www.mcafee.com/myapps/antihacker.asp.

When you are simply browsing to Web sites, information will usually travel to and from your machine without any problems. However, when you are publishing a Web site, it is a bit more complicated. In addition to the normal information exchanged, you will also be passing login credentials, and you will be passing much larger amounts of information than you do when you request a single page. Because of these differences in the way you are communicating with the remote Web server, problems are sometimes encountered that can be difficult to diagnose.

The Publishing Process

Publishing will be discussed in detail in this chapter, but it's important that you understand how the publishing process works before we go into detail. Therefore, let's look at a very high-level view of what happens when you publish a Web site with FrontPage.

1. FrontPage connects to the remote Web server and requests access to publish the site.

2. The Web server checks to see if the request coming in should be allowed to publish. At this initial point, access will always fail and the Web server will usually send a request for you to enter a username and password.

3. You enter your username and password and submit it to the Web server.

4. The Web server takes the username and password you entered and verifies them. Assuming that the login is successful, publishing proceeds with the next step.

5. The Web server checks to see if you have sufficient permissions to publish. If you do, publishing proceeds with the next step. If you do not, you are prompted again for the correct username and password.

6. Assuming that you are successfully authenticated, FrontPage generates a list of files on the remote Web server and a list of files on the local Web server. It does this by checking its metadata.

7. FrontPage displays which files it intends to publish depending on the current settings.

8. If you accept the current publish settings, FrontPage begins the transfer of all files to be published.

9. After the files have been transferred, FrontPage completes the process by recalculating hyperlinks on the remote Web site.

Failures in publishing with FrontPage almost always occur at step 4 or 8.

For more information on FrontPage metadata, see "What Is a Web Site," p. 252.

Common Reasons for Publishing Problems

At step 4, your username and password are verified by the Web server. Many times a failure at this point is caused by incorrect entries on the part of the user. However, there are cases in which authentication will fail because of server configuration.

Microsoft Web servers can use a type of authentication known as Windows Integrated authentication. (This type of authentication is commonly referred to as NTLM authentication, but Microsoft no longer uses that terminology.) Windows Integrated authentication was designed to be used on a Windows network. It allows users to log in to a network only one time, and that single login is used for other network resources that are requested during that login session. When the user requests another network resource that requires a username and password, the credentials used when he initially logged on are passed automatically instead of the user being prompted again.

Windows Integrated authentication is extremely beneficial in a Windows network environment, but it was never designed to be used on the Internet. Even so, many hosting companies and ISPs will enable Windows Integrated authentication because it is a very secure method of authentication. This can cause problems because on the Internet, your username and password are often not passed directly from your machine to the remote Web server. Many times, another computer will pass your username and password on your behalf. Windows Integrated authentication is designed to fail when this happens, and when it does, you will be continuously prompted for a username and password. After three attempts, you will be denied access. The solution to this problem is to have your host enable Basic authentication on the Web server.

NOTE

For more information on authentication types in Microsoft Web servers, read Internet Information Services Administration from Que Publishing.

The other common cause of problems when publishing is caused by the remote Web server timing out because of a lengthy file copy process. Occasionally, the hosting company or ISP can increase the timeout period on the Web server to correct this problem, but you are often better off breaking up a large site into smaller subsites. By breaking up your Web site into smaller subsites, smaller portions of the entire site are transferred when publishing and you stand a lesser chance of timeout problems.

Publishing is easily one of the toughest problems to troubleshoot with FrontPage because problems that you encounter are often not isolated to your machine. You also often have to rely on the support of your hosting company to assist in troubleshooting. Unfortunately, many hosting companies don't offer the level of service they should when publishing problems occur. Choosing a reliable host is essential in order to avoid unnecessary frustrations when problems occur.