DESIGNING
`
`AND MANAGING
`
`
`
` AN EFFECTIVE
`WEB SITE
`
`
`
`I
`
`Includes coverage of:
`
`V
`
`' 0 Java and VRML
`
`0 UNIX, Mac, and Windows
`
`servers and maintenance
`
`tools
`
`0 HTML 3.0 and the
`
`Netscape extensions
`
`. 0 CG! scripting
`
`it ERIC TILTON - CARL STEADMVAN - TYLER JONES i
`
`A|arm.com. v. Vivint
`|PR2015-01977
`Petitioner A|arm.com's Exhibit 1033
`1033.0001
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0001
`
`Alarm.com. v. Vivint
`IPR2015-01977
`
`

`
`
`
`Don Mills, Ontario - Wokingham, England - Amsterdam
`Bonn - Sydney - Singapore - Tokyo - Madrid - San Juan
`
`Eric Tilion, Curl Sieadman, and Tyler Jones
`
`A V
`
`V
`
`Addison-Wesley Developers Press
`
`Reading, Massachusetts - Menlo Park, California - New York
`
`Paris - Seoul - Milan - Mexico City - Taipei
`
`Petitioner A|arm.oom-'seExhibit—1033««L
`1033.0002
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0002
`
`

`
`Many of the designations used by manufacturers and sellers to distinguish their
`products are claimed as trademarks. Where those designations appear in this
`book, and Addison-Wesley was aware of a trademark claim, the designations
`have been printed in initial capital letters or all capital letters.
`
`The authors and publisher have taken care in preparation of this book,
`but make no expressed or implied warranty of any kind and assume no
`responsibility for errors or omissions. No liability is assumed for incidental or
`consequential damages in connection with or arising out of the use of the
`information or programs contained herein.
`
`Copyright © 1996 by Eric Tilton, Carl Steadman, and Tyler Jones
`ISBN 0-201-48959-7
`
`All rights reserved. No part of this publication may be reproduced, stored in a
`retrieval system, or transmitted, in any form or by any means, electronic,
`mechanical, photocopying, recording, or otherwise, without the prior written
`permission of the publisher. Printed in the United States of America. Published
`simultaneously in Canada.
`
`Sponsoring Editor: Kim Fryer
`Project Manager: Vicki L. Hochstedler
`Cover design: Ann Gallager
`Setin 11-point Palatino by the Clarinda Company
`
`1 2 3 4 5 6 7 8 9 -MA- 9998979695
`First printing, December 7995
`A-W Developers Press is a division of Addison-Wesley Publishing Company.
`Addison-Wesley books are available for bulk purchases by corporations,
`institutions, and other organizations. For more information please contact the
`Corporate, Government and Special Sales Department at (800) 238-9682.
`
`Find us on the World-Wide Web at:
`http://www.aw.com/devpress/
`
`-
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0003
`
`

`
`
`
`HTTP Servers
`
`This chapter provides an overview of available HTTP servers on
`three major platforms: Unix, Microsoft Windows, and the Macin-
`tosh. Several HTTP servers are reviewed, and detailed installation
`information is provided for three of the most popular: NCSA
`httpd (version 1.4), Windows httpd (version 1.4d), and MacHTTP
`(version 2'.2).
`
`At this point, we will begin to deal with technical issues that are
`important to server administrators, such as server configuration. If
`you are not a server administrator, you may want to skip to Chap-
`ter 7, Maintenance and Reporting Tools.
`
`
`H1TP Servers-
`
`Choosing a Server
`
`The HTTP server is the cornerstone of your Website, providing
`the mechanism by which the documents in your infostructure are
`served to clients like Arena and Netscape. A server is vitally im-
`portant; without a server of some sort, you will have no infostruc-
`ture at all.
`
`The server you pick can have a dramatic effect on the kinds of
`content you can provide. Different servers provide different levels
`of functionality, from simply serving static documents, to serving
`dynamic documents and imagemaps Via CGI, to providing multi-
`ple ’’virtual servers” (accessed with different domain names) on a
`single machine. Performance also varies from server to server;
`many of the commercial servers provide substantially better per-
`
`109
`
`Petitioner A|arm.com's Exhibit 1033
`1033.0004
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0004
`
`

`
`1 10
`
`Chapter 6 ° HTTP Servers
`
`
`
`D The Hfl'P Protocol
`
`HTTP, the Hypertext Transport Protocol, defines a
`simple mechanism for retrieving and interacting
`with hypermedia “objects,” whether they be HTML
`documents, GIF or JPEG images, CGl scripts, or
`any other sort of document.
`It is independent of
`(although often associated with) HTML; HTTP
`simply defines a means of transportation, not a
`means of representing information.
`
`HTTP is a stateless protocol. This means that,
`while -a client and a server may interact several
`times, the server does not try to remember any-
`thing about what the client has done in the past.
`This in contrast to FTP, where a client maintains a
`connection for the duration of an FTP session,
`and information like the current working directory
`and the user’s ID is remembered between file
`
`transfers. One advantage of HTTP is that a con-
`nection does not need to be maintained between
`the client and the server for the duration of the
`session; once a document has been downloaded,
`the user can read or use the document without
`also maintaining a costly connection to the server.
`The drawback to this is that each time the client
`
`wants another document from the server, a con-
`nection must be reinitiated (a process that can
`sometimes take longer than downloading the doc-
`ument itself, especially in the case of small col-
`ored list bullets).
`
`Another feature that distinguishes HTTP from FTP
`is the ability to do content negotatiation. With con-
`tent negotiation, the client can send a list to the
`server of which Internet Media Types (see Appen-
`dix B) it can accept, and the server can compare
`this to the various formats it may have a particular
`document in. The server can then send whichever
`
`format best suits the client’s needs. While this fea-
`ture is not yet widely implemented, clients and
`servers that support
`it (such as the emacs-w3
`client and the Apache server) are starting to ap-
`pear
`
`HTTP supports several methods of interaction be-
`tween clients and servers,
`including GET, POST,
`HEAD, PUT, LINK, and UNLINK. GET, POST, and
`HEAD are the only commonly supported methods.
`GET is the most common, and is used to retrieve
`documents. POST is for submitting information to
`be dealt with by an object (such as a program); it
`is predominantly used for the transmission of form
`data to a CG! script (see Chapter 8, CGI). HEAD is
`used to get the HTTP header for a document,
`which includes information such as when the doc-
`ument was last modified (which is useful for mak-
`ing sure that caches of documents are current
`without retrieving entire documents). The addi-
`tional methods are part of theproposed HTTP 1.0
`specification, and anticipate browsers that will
`eventually also become editors, allowing authors
`to annotate and edit documents with the same tool
`that they navigate them with.
`
`The current version of HTTP is 1.0, and it is in the
`process of becoming a formal specification as we
`write this. Future directions of HTTP include sup-
`port for encryption (such as S-HTTP, described in
`Chapter 9, Security), and for allowing multiple re-
`quests with a single connection (HTTP-NG). For
`more information about HTTP, take a look at
`
`http: //www.w3 . org/hypertext/WWl/W
`Protocols /OVerview.html
`
`
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0005
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0005
`
`

`
`
`
`I IHTTP Servers I
`
`
`
`
`
`formance than their free counterparts. Encryption-—important if
`you want to transmit or receive sensitive information (such as
`credit card numbers)——is still only rarely available in servers, with
`the Netscape Commerce Server being the most notable.
`
`One important consideration is the platform on which you run
`your server. Traditionally, Unix has been the platform of choice for
`Internet servers, and most Web servers available are available on
`this platform. Several of the Unix servers are free, and a few———the
`Webmaster Starter Kit (which is free), and the Netscape servers
`(which are not)—are remarkably easy to install and maintain (via
`forms—driven interfaces). In addition, the Unix operating system
`can provide exceptional performance for your server, especially if
`you invest in a powerful Unix machine.
`
`The flip side to choosing the Unix platform is that most Unix
`workstations are expensive, and equivalent performance can often
`be found more cheaply by investing in high—end personal comput-
`ers. PowerPC-based Macintoshes-and Pentium-class Windows
`machines are becoming increasingly affordable and increasingly
`powerful, and several servers have become available for these
`platforms. In addition to the cheapness of the hardware, there is
`the extra benefit of a more genial operating environment than
`Unix, which can make installation and support easier. One such
`server—WebSite—stands outwith sophisticated graphical Web
`analysis and development tools, and an interface that takes advan-
`tage of the user-friendly nature of Microsoft Windows. Unfortu-
`nately, no reliable free servers are available on the Mac or Win-
`dows platforms (although Windows httpd is free for personal and
`educational use), but the costs of the servers are more than made
`up for in the savings on hardware. Also, most of the more sophis-
`ticated servers require a more sophisticated operating system,
`such as Windows NT or Windows 95.
`
`The cheapest option may be to invest in one of the ”free” Unixes,
`such as Linux or FreeBSD, that are available for Intel-based ma-
`chines. Any of the free servers will run on these machines, allowing
`you to turn a Pentium-class (or even a 486-class) machine into a
`powerful, cheap workstation. The major advantage is that this al-
`lows the use of some of the more sophisticated servers which are
`available on the Unix platform, especially as the free options for
`
`Petitioner A|arm.com's Exhibit 1033
`1033.0006
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0006
`
`

`
`I 12
`
`Chapter 6 ° HTTP Servers
`
`_¥?_
`
`'
`
`both Windows and Mac are not impressive. The major caveat with
`this solution is that you lose in technical support what you gain in
`savings—and while Linux and FreeBSD are remarkably stable, they
`are not guaranteed to be reliable. Using a free Unix is a viable option
`for the technically savvy (and adventurous), but it is probably not a
`wise idea for an organization that can afford a commercial solution.
`
`In summary:
`
`i
`
`0 When deciding between a free or a commercial server, remem-
`ber that most free servers offer almost the same set of features
`as their commercial counterparts. However, commercial offer-
`ings often provide better performance, and offer features like
`encryption. Also, don't undervalue technical support.
`
`0 When choosing a platform, remember that Unix is often able to
`provide superior performance to Windows 3.1, or the Macin-
`tosh. In addition, several good free servers are available for
`Unix. On the other hand, Unix is expensive in terms of hard-
`ware and support costs.
`
`Evaluate your needs before choosing a server, and find one that
`provides the features you require, plus some room to grow. And
`remember that you can always start out with a free server and up-
`grade to a commercial one at a later point with a minimum of ef-
`fort, should it turn out to be necessary.
`'
`
`We will review several servers in the next few sections, but this is
`by no means an exhaustive list. We have tried to pick out the most
`notable servers for each platform, and to give an overview of their
`features (and their flaws), and to provide useful criteria by which
`to pick a server. Since we were not able to adequately review all
`available servers, each section ends with a list of other available
`servers, with pointers to on—line information for each.
`
`Unix
`
`In this section we discuss a few of the popular servers available on
`Unix platforms. Unix can refer to many different operating sys-
`tems, including those supplied by vendors (such as SunOS and
`Solaris), and freely available clones (such as Linux and FreeBSD).
`In general, these servers should work on any Unix platform, espe-
`cially if source code is supplied.
`
`Petitioner A|arm.com's Exhibit 1033
`1033.000?
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0007
`
`

`
`H7TP Servers
`
`1 I3
`
`NCSA httpd 1.4 W
`
`The NCSA (National Center for Supercomputing Applications, at
`the University of Illinois at Urbana-Champaign) httpd was devel-
`oped in conjuction with the popular Mosaic browser. (httpd is an
`acronym for Hypertext Transport Protocol Daemon. Daemon is a
`term often used to describe Unix processes that run constantly in
`the background, and perform tasks that are not directly controlled
`by a user, such as serving Web documents. The word is not capi-
`talized because it is the name of the actual server executable-
`which, like most Unix executables, is not capitalized.) While it was
`not the first server available, it quickly became popular along with
`Mosaic as the back end for Web applications, and it has main-
`tained this popularity. Many of the other offerings we describe
`here are based on this server, and one of the primary developers of
`the Netscape Servers cut his teeth developing this server.
`
`Features
`
`NCSA httpd provides a rich set" of features, including a flexible
`definition of your server's ”virtual document tree,” dynamic doc-
`uments, access control, Common Log Format access logs, and a
`fast ”preforking”'architecture. _
`
`Virtual document tree: httpd provides a set of configuration op-
`tions for mapping your disk’s filesystem into a virtual document _A
`tree, so that you can provide to the world only those documents
`you wish to provide, rather than all files on your machine. This in-
`cludes the ability to specify a directory in your filesystem which
`will serve as the root of your server. For example, if your server
`root directory is / usr / local / web/ documents, then when a
`client tries to retrieve http : / /www. freedonia . com/people.
`html, this request is mapped on to the physical file / usr/ local /
`web/ documents /people . html instead of onto /people
`.html. The standard scheme used by Web servers is to make
`available only (and all) of the files in this server root directory and’
`in all subdirectories of the server root directory.
`
`To add flexibility to this scheme, you can include directories that
`are not subdirectories of the server root. httpd provides configura-
`tion options for mapping directories in your filesystem (such as
`
`Petitioner A|arm.com's Exhibit 1033
`1033.0008
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0008
`
`

`
`Chapter 6 ° HTTP Servers
`l l4
`
`
`making the Unix manual pages available via your server, by map-
`ping /usr/man onto a virtual /manual s directory for your Web
`server). In addition, httpd provides an option for easily providing
`users with virtual directories in your Web server's document tree.
`You can specify that if a user (such as j smith) has a certain sub-
`directory in his or her home directory (such as publ ic_html)
`that it should be mapped on to a virtual directory of the form
`~user (in this example, ~j smith).
`
`Dynamic documents: NCSA httpd also provides CGI (Common
`Gateway Interface) scripting, for providing dynamic documents.
`This capability allows for quite a bit of flexibility in the sorts of
`services you provide; in fact, most of the features provided in
`other servers can be implemented (at the cost of efficiency) as CGI
`scripts. For example, imagemapping support and user authentica-
`tion are provided in the NCSA server by means of supplied CGI
`scripts. CGI is discussed in depth in Chapter 8.
`
`Another feature provided that relates to dynamic documents is
`the ability of the server to modify a static document with special
`commands for the server embedded in the HTML document.
`These embedded commands (called server—side includes) can be
`used to include other documents (such as headers or footers), to
`insert information about the file (such as when it was last modi-
`fied), or to insert the output of a CGI script.
`
`Access Control: In order to provide finer control over how docu-
`ments are served from the virtual document tree, NCSA httpd pro-
`vides mechanisms for access control. Access to documents and
`directories can be limited to only certain hosts (or denied access to
`certain hosts) or explicitly not served to any host. Similarly, access
`can be allowed (or denied) only to certains users or groups of users.
`This allows you to provide subscription-based services or to pro-
`vide services limited only to your local user base (without requiring
`that your local user base be using the service from local machines).
`The access control mechanism is not limited to allowing and deny-
`ing usersand hosts. It is also possible to reconfigure some of the
`global configuration options on a per-directory basis (such as
`changing the default file type from text / html to text / plain
`in a directory full of plain ASCII documents, instead of giving
`each document the suffix . txt).
`
`Petitioner A|arm.com's Exhibit 1033
`1033.0009
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0009
`
`

`
`
`
`HTTP Servers l l 5
`
`It is also possible to enable the serving of CGI scripts in arbitrary
`directories. The default behavior for CGI scripts is to provide cer-
`tain ”script” directories in which all documents are assumed to be
`CGI scripts, and are executed upon retrieval. This makes sense
`from a security standpoint, especially if you have numerous peo-
`ple providing information through your Web server, because each
`CGI script is executed with the same user permissions as your
`Web server is executed. However, it may be desirable (especially if
`you have a small and trusted user base) to allow CGI scripts to re-
`side in directories alongside static documents. The access control
`mechanism allows you to enable or disable this on a per—directory
`basis.
`
`Logging: NCSA httpd supports the NCSA/CERN Common Log-
`file Format, a standard format for access logs that the majority of _
`servers now support. This means that most log analysis tools will
`work with the logs produced by this server (and any derivitive
`servers). Since most servers support this format, this means the
`bulk of log analysis tools will work with the bulk of servers.
`
`Fast preforking architecture: In versions prior to 1.4, when httpd
`received a request for a document from a client, it would create
`another httpd process to service. the request. Unfortunately, this
`requires a fork ( ) Unix system call, which is a relatively costly
`process in terms of performance. This becomes readily apparent
`when a browser such as Netscape requests several documents
`from the server in parallel (such as a document's inlined images),
`and the server must spawn four simultaneous copies of itself in
`order to service the request.
`
`The 1.4 version of httpd addresses this problem by preforking a
`set number of servers when it is first run. The master httpd pro-
`gram uses this pool of available servers to service requests. Upon
`receiving a request, instead of forking a new process to handle it,
`it finds an existing idle process and hands the request off to it.
`This technique dramatically speeds up handling of requests, and
`is most effective for sites that expect a large number of requests
`(over 100,000 a day, for example);
`
`Limitations: Two features that are absent are built-in searching ca-
`pabilities (such as the ability to full—text or keyword index the
`server) and any maintenance tools. On the other hand, it is possi-
`
`Petitioner A|arm.com's Exhibit 1033
`1033.0010
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0010
`
`

`
`- b
`
`le to use other tools, such as a WAIS server, to provide an index
`to your server; and maintenance tools from other sources are read-
`ily available (see Chapter 7).
`
`Evaluation
`
`NCSA httpd is the standard Web server, and it provides a good
`benchmark against which other servers can be evaluated. It pro-
`vides a rich set of features, and is a solid choice for almost any ap-
`plication. While the server does not provide some advanced fea-
`tures (such as built—in maintenance tools, full—text indexing, or
`encryption), many of these features can be implemented via the
`CGI interface or with programs available from other sources
`(some of which we will discuss in later chapters). Also, impor-
`tantly, the most recent release has addressed problems with earlier
`releases, and has become competitive with commercially available
`servers in terms of speed.
`
`Overall, this is a solid and usable server. It should fulfill the needs
`of most organizations, and has the added benefit of being freely
`available from NCSA. Precompiled executables are available for
`several platforms, and the source code is also available and should
`compile for most Unix platforms for which executables are not
`available. Especially if you already have a Unix platform avail-
`able, this server deserves a serious look.
`
`5
`
`NOTE: Versions prior to 1.4 have two significant flaws. The first
`is the performance flaw addressed by the preforking ar-
`chitecture (see the previous Features section). The second
`flaw is security-related: it is possible for a client request
`to overrun the space that the server uses to store text in-
`formation, which in certain situations can allow outside
`intruders to run programs on your machine with the
`same user privileges that your Web server has. Fortu-
`nately, version 1.4 addresses both of these problems.
`
`Availability
`
`NCSA httpd is available via FTP at
`
`ftp: / / ftp . ncsa . uiuc . edu/Web/httpd/Unix/ncsa_httpd
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0011
`
`l l 6
`
`Chapter 6 ° H7TP Servers
`
`A
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0011
`
`

`
`
`
`
`
`IEvaluation I I
`
`and on—line documentation is available at
`
`http://hoohoo.ncsa.uiuc.edu/
`
`NCSA httpd source code is in the public domain (at least, through
`version 1.4), and the server can be freely used for any purpose. It
`is possible that’NCSA may change these terms for future releases,
`in which case Apache (discussed later in the chapter) may become
`a more Viable alternative.
`
`EIT’s Webmasters Starter Kit
`
`The Webmaster’s Starter Kit is based on the NCSA httpd (Version
`1.3), with a few enhancements (as detailed in Features, next). The
`biggest difference is that administration of the server is through a
`form—based interface—the administrator uses a browser such as
`Mosaic to change configuration options and to enable and disable
`options. EIT (Enterprise Integration Technologies) has developed
`this server as an experiment in providing easier ways to get
`started as an infostructure provider.
`
`Features
`
`The Webmaster’s Starter Kit, being based on NCSA httpd, shares
`many of the same features. In addition, it includes some enhance-
`ments, such as form—based administration, additional configura-
`tion options, and additional maintenance and design tools.
`
`Based on NCSA httpd: The Starter Kit is based on the source code
`for Version 1.3 of the NCSA httpd. This means that it shares almost
`all of the features as were described inthe previous NCSA httpd
`section, except for those introduced in 1.4 release.
`
`Forms-based administration: The Starter Kit is most impressive
`because of the ease of installation and administration that is pro-
`vided by its form—based interface. Installation is a matter of point-
`ing a Web browser’ at the Starter Kit installation page, and follow-
`ing the instructions. Administration is similarly performed,
`through a password-protected set of forms on your own server.
`
`Additional configuration options: The Starter Kit includes several
`additional configuration options. These include the ability to set
`additional environment variables to pass to CGI scripts, the ability
`
`Petitioner A|arm.com's Exhibit 1033
`1033.0012
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0012
`
`

`
`118
`
`Chapter 6 - HITP Servers
`
`to prevent the Web server from accessing any files outside of a
`particular directory and its subdirectories (in order to prevent
`compromised servers from being used to retrieve other documents
`from your hard drive——see Chapter 9), and the ability to automati-
`cally restart the server when it crashes without human interven-
`tion. The Starter Kit also extends the NCSA access control mecha-
`
`nism so that certain domains (or users) can be prioritized, so that
`they can get better (or worse) response times relative to other do-
`mains / users. Finally, there is a provision for ”polite” downtime,
`so that the server can turn away users with an informative mes-
`sage when you are performing maintenance Work.
`
`Additional maintenance and design tools: The Starter Kit in-
`cludes some helpful tools for getting started. These include a Web
`construction kit (which, at present, consists of a form-based inter-
`face for generating a homepage); a C library for CGI scripts; a Web
`maintenance tool for verifying links; a CGI script that represents
`e—mail as hypertext; and logfile reporting tools.
`
`These areall useful tools, and many Variants on them are available
`in many locations (see Chapter 7). However, it is very handy to
`have them packaged with the server itself, rather than having to
`hunt them down.
`
`Evaluation
`
`The Starter Kit is anice package, largely because it provides all
`of the functionality of the NCSA server, and can be configured,
`installed, and maintained via any Web browser that supports
`forms. This can make this a much easier Web server to maintain
`
`than standard NCSA httpd, which is a big advantage if you do not
`want to devote your Unix support staff to the care and feeding of
`yO11I' server.
`
`On the other hand, the Starter Kit is, as the name implies, a ”start-
`er kit.” It is more of a proof—of-concept than a product, and it is
`not undergoing as much development as many of the other
`servers listed. The current Starter Kit (as of this writing) is still
`based on the 1.3 NCSA code, which means that it shares the per-
`formance bottleneck described in the NCSA httpd section. How-
`
`Petitioner A|arm.com's Exhibit 1033
`1033.0013
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0013
`
`

`
`
`
`Evaluation l l9
`
`ever, the security problem with version 1.3 (also described previ-
`ously) has been addressed in the current release.
`
`If you were considering using NCSA httpd, but are put off by the
`task of installation and configuration, this server is a good alterna-
`tive. However, if you are interested in the extra performance gain
`in the latest version of NCSA, you'll want to wait until the Web-
`master's Starter Kit has been updated to reflect the 1.4 revision
`(Which may well happen by publication time).
`
`NOTE:
`
`If you are planning on using your server for commercial
`purposes, you will not be able to use the Starter Kit. EIT
`allows you to use their server for ”academic, research, or
`internal businesspurposes only.”
`
`A final thought: the optional extensions are helpful tools, and can
`be used independently of the server itself. You may want to con-
`sider getting them, even if you do not use the Starter Kit, espe-
`cially if you _are using an NCSA-variant server. One of them,
`the Link Verifier, is discussed in detail as a separate package in
`Chapter 7.
`
`Availability
`
`The Webmaster’s Starter Kit is available at
`
`http: / /wsk . eit . com/wsk/doc/
`
`Installation requires an account on a Unix machine connected "to
`the Internet, and a browser that supports forms.
`
`The server is available, as just noted, for ”academic, research, or
`internal business purposes” only, but (within those restrictions) is
`freely available.
`
`Apache 0.6.5
`
`Apache (version 0.6.5) is a play on A PAtCHy Server, and that is
`what it is, a series of patches to the NCSA server. These patches
`add some powerful functionality to the NCSA server, including
`the ability to provide several virtual hosts, and to use content ne-
`gotiation to provide different documents to different clients (so
`that a user using a text—based browser can receive a text—based
`
`Petitioner A|arm.com's Exhibit 1033
`1033.0014
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0014
`
`

`
`Chapferé - H7TP Servers
`I20
`
`
`Features
`
`Apache shares many of the same features as the NCSA httpd,
`along with several enhancements. These include virtual hosts,
`content negotiation, faster user authentication, ”send as is” file
`types, speed enhancements, and some additional configuration
`options.
`
`Based on NCSA httpd: Apache is based on the source code for
`version 1.3 of the NCSA httpd. This means that it shares almost
`all of the features described in the NCSA httpd section, except for
`those introduced in 1.4 release.'However, it addresses many of the
`same problems "in NCSA 1.3 that NCSA 1.4 does, including the se-
`curity and performance issues mentioned in the NCSA httpd sec-
`tion, as well providing other improvements.
`
`Virtual hosts: If you are interested in providing servers for com-
`panies or organizations that want an on—line presence, but aren't
`interested in maintainingtheir own machines on the Internet,
`Apache can emulate multiple ”virtual” servers. That is, if the ad-
`dresses www. freedonia. com and techno {nomi . com both
`point to the same machine, Apache allows ht tp : / /www. free-
`donia . com/ and http: / /techno . nomi . com/ to return differ-
`ent homepages (and different document trees). In this way, you
`can serve distinct infostructures with distinct names with the same
`physical hardware.
`'
`
`Content negotiation: This is a clever feature that provides a
`mechanism for catering to the wide range of capabilities in
`browser software. Most browsers will send information to the
`server about the kind of content they are willing to accept (such as
`whether they can accept GIF or IPEG images). Apache can use this
`information to return the best format for a browser. Thus, instead
`of creating two different versions of a document——one that has in-
`lined GIFs, and one with inlined ]PEGs—you can create one ver-
`
`Petitioner A|arm.com's Exhibit 1033
`1033.0015
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0015
`
`

`
`
`
`Eva/uofion I Z I
`
`sion of a document and allow Apache to negotiate with the
`browser to find the correct image format to retrieve.
`
`Faster user authentication: Apache includes a faster mechanism
`for user authentication than is supplied by ”Vani1la” NCSA 1.3.
`This is used extensively by sites such as HotWired, that have ex-
`tensive user databases which are constantly accessed.
`
`”Send as is” file types: Apache supports certain files that should
`be sent =’.’as is,” including HTTP headers. This allows for extreme
`fine-tuning of server behavior, without having to run a CGI script.
`
`Speed enhancements: Apache is an optimized version of NCSA
`httpd 1.3, offering a significant boost over the unoptimized ver-
`sion. It does not yet include the preforking architecture of 1.4 (at
`the time of this Writing), but it is in the works and will probably
`be available by the time you read this.
`
`Additional configuration options: Apache also supports custom
`error responses, the ability to define multiple defaults for directory
`index files (such as " index . html " or '-' home . html " ), and several
`other enhancements for CGI scripting and server configuration.
`
`Evaluation
`
`Apache is billed by its developers as a plug-in replacement for
`NCSA 1.3, and by the time you read this, it should also be a plug-
`in replacement for NCSA 1.4. It provides the same feature set,..as
`Well as several additional modficiations. The speed enhancements
`and the support for content negotiation make this server an ex-
`temely attractive option; and the possibility that the terms of the
`NCSA license may change (which may mean that anything after
`1.4 will no longer be freely available, at least for commercial use)
`may make this an even more attractive server in the future.
`
`On the other hand, this server is an independent development ef-
`fort, and is (at this writing) still in beta testing. Since it is based on
`a stable server, most features should work as expected, but there is
`no technical support and some features may be buggy or still in
`development at any time. Still, if you require the sort of enhance-
`ments provided by this server, and have the systems support staff
`to provide proper care and feeding, it is a compelling choice. Espe-
`
`Petitioner A|arm.com's Exhibit 1033
`1033.0016
`
`Petitioner Alarm.com's Exhibit 1033
`1033.0016
`
`

`
`122
`Chapter 6 ° HTTP Servers
`
`
`cially since, as with most of the freely available software available
`on-line, it does work extremely well, and failures are the exception
`rather than the rule.
`
`Availability
`
`Apache is available via FTP at
`
`ftp://ftp.apache.org/apache/dist/‘
`
`The documentation for the Apache server project, as well as a list
`of mirror sites from which the server can be retrieved by FTP is at
`
`http://www.apache.org/apache/
`
`The server is freely available and usable.
`
`WN 1.04
`
`WN (version 1.04), written by John Franks of Northwestern Uni-
`versity, is designed to provide useful tools as part of the server
`package, such as indexing, searchin