Special Edition Using HTML 2nd Edition - Chapter 2 How Web Browsers and Servers Work Together Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of United States copyright laws. For information, address Que Corporation, 201 West 103^rd Street, Indianapolis, IN 46290 or at support@mcp.com.

Notice: This material is excerpted from Special Edition Using HTML, 2nd Edition, ISBN: 0-7897-0758-6. This material has not yet been through the final proof reading stage that it will pass through before being published in printed form. Some errors may exist here that will be corrected before the book is published. This material is provided "as is" without any warranty of any kind.

Chapter 2 How Web Browsers and Servers Work Together

by Mark Brown

The steps that occur when you view a Web page
The difference between HTTP and HTML
What a URL is
How browser programs differ in the way they display Web pages
Which server and browser programs are the most popular

They say that the camera never lies. A photograph is a record of a real scene as it was captured by the camera's lens.

On the other hand, two artists never paint the same scene the same way. Every element is subject to the artist's interpretation. One artist might paint a photo-realistic image that's almost sharper than reality; another might render an abstract smear that communicates mood more accurately than it portrays the scene. They might move, add, remove, or alter objects or change lighting to suit their depictions of the scene.

The World Wide Web works more like painting than it does like taking photographs. A Web server "serves up" a page over the Internet, and a Web browser program interprets it. The results may be almost as different as the two painting styles described above. This is the central, surprising truth about the World Wide Web: what you see on a Web page is described, not defined, by its HTML code. It is up to the user's browser program to render it in its final form.

Many new Web developers are shocked to discover that they have so little control over the final appearance of their pages. But, for better or worse, that's how the Web works. If you want to create Web pages that can be viewed accurately by a wide range of WWW users, you're going to have to be aware of the different server and browser programs that are out there and how they work together.

How the Web Works

The World Wide Web has a client/server architecture. This means that a client program running on your computer (your Web browser) requests information from a server program running on another computer somewhere on the Internet. That server then sends the requested data back over the Net to your browser program, which interprets and displays the data on your screen. Figure 2.1 shows the whole process graphically. The following steps explain the process:

You run a Web browser client program on your computer.
You connect to the Internet-at work or school via a direct T1 or T3 line; at home via a modem dial-up connection to an Internet service provider (ISP).
You request a page from a site on the Web. Your browser sends a message over the Internet that includes the following:

The transfer protocol (http://)
The address, or Uniform Resource Locator (URL), e.g., www.somesite.net

The server receives your request and retrieves the requested Web page, which is composed in HTML (HyperText Markup Language).
The server then transmits the requested page back across the Internet to your computer.
Your browser program receives the HTML text and displays its interpretation of the page you requested.

Fig. 2.1

This is what happens when you view a page on the World Wide Web.

Many computer networks include a security mechanism called a firewall. A firewall is software (often combined with specialized hardware) that creates a barrier to keep unauthorized outside users from accessing a site. If a system is equipped with a firewall, inside users must use proxy programs to access the Internet. Although this adds a couple of steps, the fundamental process of transferring data back and forth between client and server is essentially unchanged.

You can also set up a server to run a Web site over a LAN (local area network) without connecting it to the outside world at all. This is sometimes referred to as an Intranet. In this scenario, only those connected directly to the LAN are able to access the pages on the server. Many companies use a setup like this for distributing internal information to their employees.

The Client Computer

To browse the Web, you need a client computer. There are two basic requirements for this machine: it must have a connection to the Internet and must be capable of running a Web browser program.

The Internet connection can be hard-wired, or it can be a dial-up phone connection via modem to an Internet service provider (ISP). You're most likely to have the former at work or school and the latter at home. The only difference you will notice between the two is speed; otherwise, they work identically.

There are Web browser programs for just about any computer you can name, from dumb text-only terminals running on mainframes to off-brand personal computers, such as the Amiga. (I'll list and discuss the most popular browser programs later in this chapter.)

The Server Computer

On the content-provider side of things, you need a server computer. This machine has requirements similar to those of the client computer: it must be connected to the Internet and must be able to run a Web server program.

A Web server program is often called an HTTPD, for HyperText Transfer Protocol Daemon. Daemon is computerese for a program that runs unseen in the background.

However, a Web server needs a more robust Internet connection than a Web client does. A server should ideally be hooked up to the Internet via a fast dedicated T1 or T3 line that remains connected all the time. Otherwise, people trying to access your Web site will often find that it just isn't there.

It is possible (though excruciatingly slow) to run a Web site on a dial-up line, especially if you can find an Internet service provider who will let you stay dialed in 24 hours a day without disconnecting you. However, you must make sure that your ISP can assign a permanent IP address to your machine-not a new IP address each time you connect. Otherwise, people won't even be able to find your site.

A good intermediate solution to the direct vs. dial-up problem is an ISDN line. A sort of super fast digital phone line, an ISDN line costs more than a regular phone line but much, much less than a dedicated T1 or T3 line. It also requires a special interface card for your computer. ISDN lines are offered by most phone companies in urban areas and university towns, but you'll need to find an ISP that can provide an ISDN connection too. Contact the business office of your local phone company for details.

HTTPD server software is available for a wide variety of computers (see fig. 2.2). Surprisingly, server computers don't have to be very powerful; serving up Web content is simply not that demanding. More of a concern is having a multithreaded, multitasking operating system so that the server can handle several tasks at once without bogging down. Storage is a concern, however, because Web sites are notorious for growing without limit.

Fig. 2.2

The Spry Web Server for UNIX X Windows has a rich GUI for configuration and maintenance tasks.

Communication: Requesting Information via URLs

An HTTP connection is said to be stateless. That is, no permanent connection is maintained between the server and the client. A request is made, and the connection is broken. Then a response is sent back, and the connection is broken again. This process is repeated for every request and often even for parts of a request. Programmers refer to this as a query-response model of interaction. It's the reason your browser program always seems to be saying "Waiting for reply..." in its status display line. (See the message at the bottom of fig. 2.3.)

A browser's request for information takes the form of a URL (Uniform Resource Locator), which is also referred to as a page's address or location. URLs almost always look something like this:

http://www.somesite.net/path/webpage.html

A URL is always a single, unbroken line of text with no spaces.

Web browsers generally display the URL of the Web page currently being viewed near the top of the window (see fig. 2.3).

Fig. 2.3

Web browsers let you know where you are on the Web by displaying the page's URL. Netscape shows this near the top of the display window and labels it "Location."

Here's a real world example of a URL, taken from figure 2.3:

http://www.microsoft.com/msoffice/freestuf/msword/download/ia/default.htm

The "http://" portion of the URL indicates that the browser has requested a transfer via HTTP protocol; that is, it wants a Web page. "www.microsoft.com" is the domain name of the server being queried; in this case, it's the Web server at Microsoft. The "msoffice/freestuf/msword/download/ia/" portion of the URL is the path name on the server's hard drive for the file you want. (Fortunately, this example is of one of the longer path names you're likely to run into on the Web.) "default.htm" is the name of the actual HTML file on the server; it's what is being displayed on the screen in figure 2.3.

See "Domain Names"

If the protocol portion of a URL is https:// or snews://, it means that the connection is secure. In Netscape, this will be confirmed by the presence of an unbroken security key in the lower left-hand corner of the screen.

URLs can reference not only Web pages, but just about any service on the Internet, including FTP, Gopher, WAIS, Usenet, and Telnet. You can even load in a file from your own computer! Table 2.1 shows the syntax for the various types of sites that can be accessed via a Web browser.

Table 2.1 URL Syntax for Addressing Various Types of Internet Sites

URL Syntax	Type of Access
file://	a file on your local computer
ftp://	an FTP server
gopher://	a Gopher server
http://	a Web page
news://	a Usenet newsgroup
telnet://	a connection to a Telnet site
WAIS://	a WAIS server

See "Linking HTML Documents"

The domain name portion of a URL may include a colon followed by a port number, like this:

http://www.somesite.net:80/path/webpage.htm

This tells the server to access the site via a specific assigned port.

Port 80 is the default port defined in the HTTP specification. If not given, it is assumed.

Web page file names usually end in .htm or .html to indicate that they are HTML content files. Many home pages don't have path names or file names at all. Their URLs are in a very abbreviated format:

http://www.somesite.net

These addresses access a page that is stored in the server's root directory; that is, they don't need a path name because they aren't stored in a subdirectory. Most servers also assume a default file name for the home page, such as hompage.html or index.htm. If no page file name is specified, the server will automatically serve up the default page.

URLs can point to other types of files than HTML Web pages, of course. For example, the URL http://www.somesite.net/logo.gif would display a GIF image file. http://www.somesite.net/path/program.zip would, depending on how your browser is configured, prompt you to save the specified ZIP file to disk or would decompress the file and store the resulting program files to disk.

Sometimes you may see a URL that looks something like this:

http://www.somesite.net/cgi-bin/findit&toad+frog

Servers can include gateways, which enable them to run application programs called CGI (Common Gateway Interface) scripts or programs. These are, in most ways, just like any other programs run by a computer. Depending on the machine and the gateway, CGI-bin (bin for binary) programs might be written in C, C++, BASIC, or the PERL scripting language. A URL like the one above instructs the server to run the CGI program called findit using the data toad and frog as inputs. In this example, it would be a fair guess that the server program, findit, was some sort of indexing program and that the user had instructed it to find references in its database to toads and frogs.

See "All About CGI"
See "Sample Code and CGI Scripts"

Some hyperlinks may reference a relative URL; that is, one in the same path name on the same server as the page currently being viewed. For example, if the current page is http:// 
www.somesite.net/path/thispage.html, a relative link to thatpage.html would load in the page whose absolute address is http://www.somesite.net/path/thatpage.html. This technique not only saves page creation time and space on the server, but it makes it very easy to move all of the files associated with a Web site to a new directory or even to a new machine. Only the references to the home page need to be changed; relative URLs remain the same.

Servers and HTTP

A Web server computer runs an HTTPD (HyperText Transfer Protocol Daemon) program (see fig. 2.4). The history behind the development of HTTP is told in Chapter 1, "Overview of the Web." This section will concentrate on how Web servers use HTTP to communicate with browser clients.

Fig. 2.4

NetPublisher is an HTTPD server program for Windows NT. Unlike many bare-bones UNIX servers, NetPublisher sports an intuitive GUI.

What Servers Do

When you analyze what a server does, you begin to fully realize just how much of the look and feel of the World Wide Web is in the browser program.

The browser client strips a URL down to its component parts: protocol, address, path name, and file name. From the protocol portion, it determines how it is going to interact with the server that it's addressing and how to display the data it will receive. It then calls the address contained in the URL and waits for a response from the server.

Once the server realizes that a request is coming through, it likewise checks the URL for the connection protocol (e.g., http:// for a Web page). It takes the path name and file name that it has been given, finds them on its hard drive, and sends the data off to the browser using the correct protocol.

Then it's the browser's turn again. This time it gathers in, interprets, and properly displays the data it has received.

It probably seems like there is a lot more for the browser to do in this process than there is for the server, and in the case of a simple transaction, such as viewing a Web page, that's probably true. But there's much more than that going on in the background.

For example, if there's an error somewhere along the way-such as, a request for a page that doesn't exist-the server has to send back the proper error message. If the user has requested an action that requires running a CGI program, the server has to load and run the program. This process usually means creating a custom HTML page "on the fly" that contains the results of the program's action, then sending that back to the browser.

Then, too, every data file transmitted by the server has to be properly identified by type and tagged with the appropriate MIME (Multipurpose Internet Mail Extension) data type header so the browser will know what to do with it. Most Web pages include a mix of HTML formatted text, GIF and JPEG graphics, and maybe even audio and video clips; each must be properly tagged, or the browser won't know how to interpret the pieces when they arrive.

See Chapter 1, "Introducing the World Wide Web"

Today's Web servers also include all kinds of esoterica-for example, data encryption and client authentication. These take up a great deal of the server's time, too.

Factor in the fact that a server is often handling requests from hundreds of clients at any one time, and you'll see that there's more than enough going on to keep it busy.

For more information on servers, check out the Usenet newsgroups comp.infosystems.www.servers.misc, .mac, .ms-windows, and .unix.

HTTP

The HyperText Transfer Protocol (HTTP) was designed to be quick, simple, and nonintrusive. The connection between a server and a client program (or agent) is temporary and must be reestablished for every data transfer.

The HTTP specification incorporates a whole set of methods that are used to perform the tasks associated with servicing a Web site, including information retrieval, searching, front-end updating, and annotation. The specification is open-ended, so additional functionality can be added without making the whole Web obsolete.

As discussed previously, messages are passed in a format that is similar to Internet Mail and the Multipurpose Internet Mail Extensions (MIME); gateways enable browsers to request the execution of CGI applications on the server hardware; and communication is possible with other Internet protocols, such as SMTP, NNTP, FTP, Gopher, and WAIS.

HTTP is, like these earlier protocols, a TCP/IP protocol. However, it can be implemented on top of any other protocol implementation that can communicate over the Internet or on other networks, including LANs.

The current version of the HTTP protocol specification can be found at the site
maintained by the HTTP Working Group at http://www.ics.uci.edu/pub/ietf/http/.

An Overview of Popular HTTPD Server Programs

Almost any computer platform that you can name (and some you probably can't) can act as a Web server. There are HTTPD server programs for systems as varied as multimillion-dollar mainframes and PCs costing under $1000.

Which one is best? That's a question that is highly subjective, and it's certainly beyond the scope of this book. A more important question might be, "Do I need an HTTPD server program at all?"

If you usually hook up to the Web through an Internet service provider (ISP) and are thinking about setting up a personal Web site, the answer is almost certainly no! What you need is an account on somebody else's Web server, probably that of your ISP. Most ISPs offer a place for your own home page for little or nothing if you're already using their dial-up services. For example, my local ISP charges me $30 a month for unlimited Internet access and includes a 10 megabyte UNIX account on which I can keep my own World Wide Web pages.

If you think about it, this is an incredible bargain. For $1 a day-which is less than I pay for cable TV-I maintain a Web site that can be seen by anyone in the world, 24 hours a day! And they take care of all the headaches of setting up and configuring the server, maintaining the site, and handling glitches and bugs. It's great. All I have to do is develop the content for my site, write it in HTML, and upload it to my provider.

For an example of what kind of site you can set up using somebody else's Web server, check out my personal Web site at http://www2.giant.net/people/mbrown.

Even small to medium sized companies might want to consider having an ISP host their sites rather than setting up their own Web server. It can mean a major investment of both time and money to set up a server computer, hook it up via a permanent T1 or T3 land line, install the HTTPD software, and maintain all of that hardware and software over time. If your needs are moderate, having an ISP take care of all that for you can be a major headache reliever.

You can find a searchable list of Internet service providers on the ISP Yellow Pages site at http://www.index.org/.

However, if you are developing Web pages for a college or major corporation, you'll probably want to run your own site. This is the best way to go if your site:

Is already hard wired to the Internet
Will contain a great number of pages
Needs to run custom CGI applications
Will require frequent updating
Needs to be secure

If any of these criteria describe the site you want to set up, then pick a computer platform and HTTPD server software that match your requirements.

It is beyond the scope of this book to review all of the many HTTPD servers that are currently available; nonetheless, I can discuss the ones that are the most popular. Although popularity is not exclusively determined by quality-price and compatibility are certainly major issues as well-it can serve as a good measure of which server programs are already working for a large number of sites.

The server use statistics in this section were taken from the server survey data at http://www.mirai.com/survey and from the Spry Webcrawler statistics at http://www.webcrawler.com/WebCrawler/Facts/WebFacts.html.

Accurate statistical data about Web server usage is hard to come by. Most is based on random samplings of sites or on volunteer surveys, which can be highly skewed by inaccurate survey samples. But a comparison of the best data currently available on the Web seems to lead to the following conclusions about which computer platforms are probably the most popular Web servers:

A little less than one-third of all Web servers run on Sun workstations.
About one-third of all Web sites are running on Macintoshes or on IBM-compatible personal computers with some version of the Windows operating system. These are about evenly split between the two platforms. Twice as many of the IBM-compatible sites run NT as run Windows.
The remaining one-third of all Web sites run on UNIX systems.
Only about 4 percent of Web sites run on OS/2 or other operating systems.

This breakdown is shown graphically in the pie chart in figure 2.5.

Fig. 2.5

Sun workstations, personal computers, and UNIX systems split the server market into near-equal thirds.

A little over a year ago, more than 80 percent of the servers on the Web were UNIX-based. The shift shown in figure 2.5 certainly reflects two current trends: The rapid growth of the World Wide Web has moved it beyond the confines of academia and corporate America, where UNIX is most popular, and there has been, in the last year, a proliferation of HTTPD software for platforms other than UNIX.

Let's take a look at specific servers.

One of the major reasons for UNIX's predominance has been the number of freely distributable HTTPD server programs available for it. CERN HTTPD and NCSA HTTPD have historically been the two most popular server programs on the Web, and they remain at or near the top of the list.

However, a plethora of new server programs has been introduced in the past year, and some of them are gaining market share quickly. Although there are a few new freebies-Apache, for instance-many of the fastest-growing servers are commercial packages from such companies as Netscape, Quarterdeck, and Open Market.

There are many good reasons for the fast growth of commercial Web server programs. For the price, those buying commercial servers get the peace of mind that comes with knowing that the product is fully supported, not freeware with a nebulous cloud of hobbyist developers working on it in their spare time. Then, too, these products are finished goods; they don't need to be compiled to run and are packaged with complete documentation and a full set of additional Web development software tools.

Further, commercial servers usually offer additional functionality that just isn't found in freeware servers, such as encryption and security. And finally, most of the current growth of the Web can be directly attributed to the addition of many new commercial sites. Unlike the personal and academic sites that preceded them, commercial sites aren't scared off by the $400-$5000 price tag that commercial server software carries.

Table 2.2 lists the most popular servers on the Web, as nearly as can be determined by current data. Figure 2.6 shows the same data graphically.

Table 2.2 The Most Popular HTTPD Server Software

Server	Availability	Platform(s)	Pct
NCSA	Free	UNIX/Win	41
Apache	Free	UNIX	17
Netscape	Commercial	UNIX/WinNT	13
CERN HTTPD	Free	UNIX	11
WebSTAR/MacHTTP	Comm/Free	Macintosh	17
Others	Comm/Free	Varied	1

Source: Web Servers Survey Version 2.0, January 1996, by Paul E. Hoffman, Proper Publishing, http://www.proper.com/.

Fig. 2.6

Many of the most popular Web server software in use today are freeware, but commercial servers are gaining ground.

There are, of course, a great many more HTTPD server programs available than those shown in Table 2.2. Table 2.3 lists HTTPD server programs for a variety of platforms. To find out more about any of these servers, check out Paul Hoffman's Server Comparison Chart on the Web. This site contains a wealth of data for anyone who is thinking about establishing a presence on the World Wide Web, including hypertext links to the publishers of most of the Web server programs listed in Table 2.3. Its location is http://www.proper.com/www/servers-chart.html.

Table 2.3 HTTPD Server Programs by Platform

Platform	Server
Amiga	Amiga Web Server
AS/400	Server/400
Macintosh	CL-HTTP, FTPd, httpd4Mac, MacHTTP, WebSTAR
Novell	SiteBuilder, Webware
OS/2	GoServe
UNIX	Apache, Boa, CERN, CL-HTTP, GN, NaviServer, NCSA, Netscape Commerce, Netscape Communications, Open Market Secure WS, Open Market WebServer, Phttpd, SafetyWEB UNIX, Spinner, Spry Web UNIX, TEAMate, WN
VM/CMS	Webshare
VMS	CERN, Purveyor, Region 6
Windows 3.1	FrontPage, Quarterdeck
Windows 95	Alibaba, Commerce Builder, Communications Builder, FolkWeb, FrontPage, Purveyor, Quarterdeck WebServer, SAIC, WebQuest, WebSite
Windows NT	Alibaba, Commerce Builder, Communications Builder, FolkWeb, FrontPage, HTTPS, Microsoft's Internet Information Server, NaviServer, NetPublisher, Netscape Commerce, Netscape Communications, Purveyor, Quarterdeck, SafetyWEB NT, SAIC, Spry Web NT, WebQuest, WebSite

Browsers and HTML

To a large degree, the Web is what your Web browser makes it. Because Web pages are written in HTML and because HTML is subject to interpretation, your browser profoundly affects the appearance of Web pages and, consequently, your impression of the World Wide Web as a whole.

What Browsers Do

Figure 2.7 shows the same Web page as viewed by three different browser programs: the all-text UNIX Lynx browser (upper left), an older Windows browser called Cello (upper right), and Netscape Navigator 2.0 (lower right). The fourth image (lower left) is the same page displayed by Netscape 2.0 with customized color and font settings. You can see how differently various browsers can interpret the same page and how significant user settings are in the outcome.

Fig. 2.7

The same Web page can be displayed in very different ways by different browser programs.

That's why it's important to make sure you have a good browser program (see fig. 2.8) if you're going to develop HTML documents for the World Wide Web. You want to make sure that your viewers are seeing the same pages you are.

Fig. 2.8

Netscape Navigator, shown here in version 2.0 for Windows 95, is the most popular browser program in use on the Web today. In this screen shot, Netscape displays a 3-D VRML (Virtual Reality Modeling Language) virtual world using the WebFX plug-in.

As a sort of experiment, you can simulate a Web browser program by Telneting into a Web site and executing the same command by hand that a browser would. Perform the following steps:

Run a Telnet application and log into a Web site. For most sites, you'll want to specify port 80. For example, access the Yahoo! Web site via Telnet at www.yahoo.com 0080.
Type GET index.html.
The ASCII HTML file that is Yahoo!'s home page will scroll by on your monitor.
Because HTTP is stateless, the connection is closed automatically when the document (or error message if you mistyped Step 2) is done transmitting.

For more information on Web browser programs, check out the Usenet newsgroups comp.infosystems.www.browsers.misc, .mac, .ms-windows, and .X.

HTML

HTML is not intended to be an all-encompassing, all-powerful page layout environment. HTML describes a page's look by using markup tags to indicate the relative position of elements on the page. For example, you can specify which lines of text are headings and their level of importance. You can show where in the text an in-line image should appear and whether certain blocks of text should appear with a particular type of formatting. You can even create tables and forms. With some of the most recent versions of HTML, you can create frames in which different parts of pages are displayed, put up graphic background wallpaper, and change the color of text on the fly.

See "Netscape-Specific Extensions to HTML"

See "Additional HTML Extensions Supported by Other Browsers"

HTML cannot, however, determine which font, font size, or color will be used to display text; what the screen background color will be; how the colors in graphics will be interpreted; or any of a wide variety of other variables that are at the mercy of browser programs or the users' settings of various options in their browser programs.

"Why doesn't HTML give a page creator more control?" you ask.

HTML's main appeal is that it is easy to learn and easy to use. Ease of implementation was, in fact, the major design criterion for HTML, and it worked. A recent survey of Web page creators found that over half of them learned the basics of HTML in under three hours, and another quarter took only six hours. Most said that a good book (like this one!) and the Web itself were the only tools they needed to begin creating Web pages.

HTML was also designed to be compatible across a wide range of machines, from text-only UNIX terminals to the flashiest Silicon Graphics workstation. To a large degree, that goal has been met, too. Although there will certainly be some differences in the same Web page viewed on different machines with different browsers, the results will likely be similar enough and acceptable enough to convey the information presented in the manner intended by the page's creator.

The responsibility for making sure this happens rests squarely on the shoulders of the Web developer-you! Properly applied, HTML can make your pages look good on a wide variety of platforms. The more aware you are of the differences in Web browsers, the better you'll be able to make sure your pages look good on all (or at least most) of them.

See "Accommodating WWW Users and Their Viewers"

If you really want the pages you put on the Web to retain their original look and feel, you might want to consider making them available as PDF (Portable Document Format) files. A lot of companies and organizations do, from Adobe Systems to the IRS.

A PDF file can't be read by a Web browser though-it needs an external viewer program. Adobe Acrobat is the most popular PDF format on the Web today. You can get information about Acrobat (and download a free viewer) from the Adobe Web site at http://www.adobe.com.

An Overview of a Few Popular Web Browser Programs

So which Web browser clients are the most popular? That's one with an easy answer. The most popular Web browser today is Netscape Navigator, which is used by over 80 percent of those cruising the Web. Other browsers don't account for over four percent of the market each.

Does this mean that you can, with impunity, develop only for Netscape and ignore the rest? In a word, no. First of all, there are several different versions of Netscape Navigator out there, running on UNIX, Windows, Windows 95, and Macintosh platforms. If you want to use some of the latest and greatest Netscape features-such as frames -you'll leave behind the three-quarters or more of your Netscape audience who are, as of this writing, still using Netscape 1.1. (See Chapter 15, "Netscape-Specific Extensions to HTML.") And the 20 percent of Web users who don't use Netscape Navigator are a sizable chunk of your audience too. You don't want to leave them out in the cold, do you?

Table 2.4 should give you some idea of the wide variety of client programs that are out there browsing the Web.

Table 2.4 Web Browser Programs for Various Platforms

Platform	Browser	Comments
AMIGA	Amosaic	Based on NCSA Mosaic. FTP from aminet sites in /pub/aminet/comm/net. Homepage at http://insti.physics.sunysb.edu/AMosaic/home.html. FAQ at http://www.phone.net/ATCPFAQ/amosaic.html.
	Amiga Lynx	Home page at http://www.fhi-berlin.mpg.de/amiga/alynx.html.
	EMACS w3-mode	Multi-platform browser for EMACS editor. Runs under Gnu EMACS on the Amiga. FTP from ftp.cs.indiana.edu/pub/elisp/w3.
MACINTOSH	Enhanced Mosaic	From Spyglass. Multi-platform. Commercial version of NCSA Mosaic. Can only be licensed by OEMs. Home page at http://www.spyglass.com.
	MacWeb	Available only as part of TradeVPI. See http://galaxy.einet.net/EINet/MacWeb/MacWebHome.html
	NCSA Mosaic	Multi-platform and still free (see fig. 2.9). FTP from ftp.ncsa.uiuc.edu/Mac/Mosaic.
	Netscape Navigator	Tables, HTML extensions. Free to nonprofit and educational institutions; free 90-day evaluation for individuals. Home page at http://home.netscape.com/comprod/products/navigator/. FTP from ftp.netscape.com.
MS/DOS	DOSLynx	Can view GIFs, but not in-line. FTP from ftp2.cc.ukans.edu/pub/WWW/DosLynx.
	Minuet	Both text-mode and graphics-mode display. FTP from minuet.micro.umn.edu/pub/minuet/latest/minuarc.exe.
NEXTSTEP	CERN	Out of date; editor not operational.
	WorldWide Web	Requires NeXTStep 3.0. FTP from ftp.w3.org/pub/nextapp.
	EMACS w3-mode	(see Amiga listing)
	Netsurfer	FTP from ftp://ftp.netsurfer.com/pub/Netsurfer/ Home page at http://www.netsurfer.com.
	OmniWeb	Home page at http://www.omnigroup.com/ FTP from ftp://next-ftp.peak.org/pub/next/binaries/wide-area-info/
	Spider Woman	Multithreaded, graphical. FTP from sente.epfl.ch/pub/software. Home page at http://sente.epfl.ch/.
TEXT-MODE	EMACS w3-mode	(see Amiga listing)
UNIX/VMS	Line Mode Browser	For dumb terminals. FTP from ftp.w3.org/pub/linemode.
	Lynx	For VT100. FTP from ftp2.cc.ukans.edu.
	PERLWWW	By Tom Fine. TTY-based, written in PERL. FTP from archive.cis.ohio-state.edu/pub/w3browser/w3browser-0.1.shar.
	VMS	By Dudu Rashty. FTP from vms.huji.ac.il/www/vms_client.
VM/CMS	Albert	FTP from ftp.nerdc.ufl.edu/pub/vm/www/.
	Charlotte	Written in REXX, runs on any CMS from v5 to v11. Gopher at gopher://p370.bcsc.gov.bc.ca.
WINDOWS 3.1/NT/95	Cello	From Cornell. Outdated. FTP from ftp.law.cornell.edu/pub/LII/cello
	CompuServe Mosaic	From CompuServe. Comes with CompuServe subscription.
	EMACS w3-mode	(see Amiga listing)
	Emissary	From Wollongong. Home page at http://www.twg.com.
	Enhanced Mosaic	(See Macintosh listing)
	I-COMM	Operates without a TCP/IP connection. Requires UNIX or VMS shell account. Home page at http://www.best.com/~icomm/icomm.htm.
	Internet Explorer	From Microsoft (see fig. 2.10). Many HTML extensions. Home page at http://www.microsoft.com.
	Internet Works	Now a part of Global Network Navigator and America Online. For information, contact http://www.gnn.com.
	Netscape Navigator	(See Macintosh listing)
	NetShark	From InterCon Systems. Home page at http://netshark.inter.net. Supports HTML extensions. FTP Lite version from netshark.inter.net/pub/netshark/.
	Quarterdeck Mosaic	From Quarterdeck. HTML extensions. 30-day evaluation copy downloadable from http://www.qdeck.com/qdeck/demosoft/QMosaic.
	SlipKnot	Operates without SLIP or PPP connection. Requires UNIX shell account. FTP from ftp://ftp.coast.net/SimTel/win3/internet/. Home page at http://www.interport.net/slipknot/slipknot.html.
	UdiWWW	Supports most of proposed HTML 3.0 plus Netscape extensions. Home page at http://www.uni-ulm.de/~richter/udiwww/index.htm.
	WinMosaic	From NCSA. FTP from ftp.ncsa.uiuc.edu/PC/Windows/Mosaic. Home page at http://www.w3.org/hypertext/WWW/MosaicForWindows/Status.html.
	WinWeb	Available only as part of TradeVPI. See http://galaxy.einet.net/EINet/WinWeb/WinWebHome.html
IBM OS/2	Web Explorer	Multithreaded with visual map of session. FTP from ftp01.ny.us.ibm.net/pub/WebExplorer.
	WebSurfer	From Netmanage. Included with Chameleon TCP/IP software package.
X/ DECWINDOWS	Arena	Test bed for HTML Level 3. FTP from ftp.w3.org/pub/arena.
	Chimera	Uses Athena (doesn't require Motif). FTP from ftp.cs.unlv.edu/pub/chimera.
	EMACS w3-mode	(see Amiga listing)
	Enhanced Mosaic	(see Macintosh listing)
	MMM	Tcl/Tk user interface. Supports plug-in applets written in Caml Special Light. Home page at http://pauillac.inria.fr/~rouaix/mmm.
	NCSA Mosaic for VMS	(see Macintosh listing)
	NCSA Mosaic for X	(see Macintosh listing)
	Netscape Navigator	(see Macintosh listing)
	Quadralay Mosaic	From Quadralay. Commercial Mosaic for UNIX (Windows and Macintosh versions planned). Home page at http://www.quadralay.com/products/products.html#gwhis.
	TkWWW	UNIX Browser/Editor for X11. Supports WSYIWYG HTML editing. Home page at http://www.w3.org/hypertext/WWW/TkWWW/Status.html.
	Viola for X	Two versions: one using Motif, one using Xlib. HTML Level 3 forms and tables. FTP from ora.com/pub/www/viola. Home page at http://xcf.berkeley.edu/ht/projects/viola/README.

Fig. 2.9

NCSA Mosaic was the original Web browser program. It has kept up well and is still available for Macintosh, Windows 3.1, Windows NT, Windows 95 (shown here), and X Windows systems. Many other browsers are derived from the original NCSA Mosaic source code.

Fig. 2.10

Microsoft's Internet Explorer (shown here in its v2.0 release for Windows 95) is one of the most recent and one of the most powerful Web browser programs currently available.

The information in this table came from the World Wide Web Frequently Asked Questions (FAQ) list, which is maintained by Thomas Boutell. You can download the latest version at http://www.boutell.com/faq/ or http://www.shu.edu/about/WWWFaq/.

Batch-mode browsers retrieve the contents of a URL specified on the UNIX shell command line and are intended for use in scripts. (Most of the text-based UNIX browsers can also do this.) One is available at ftp.cc.utexas.edu/pub/zippy/url_get.tar.Z. Another, written in extended Tcl (tclX), is available at http://hplyot.obspm.fr/~dl/wwwtools.html.

Internet & New Technologies Home Page - Que Home Page
For technical support for our books and software contact support@mcp.com
© 1996, Que Corporation