doc/fastcgi-whitepaper/fastcgi.htm

   1 <HTML>
   2    <HEAD>
   3       <TITLE>
   4          FastCGI
   5       </TITLE>
   6       <META NAME="GENERATOR" CONTENT="Internet Assistant for Microsoft Word 2.0z">
   7 <STYLE TYPE="text/css">
   8  div.c5 {font-family: Arial Narrow; font-size: 80%; text-align: center}
   9  span.c4 {font-family: Courier}
  10  tt.c3 {font-family: Courier}
  11  div.c2 {text-align: center}
  12  div.c1 {color: #FFFFFF; font-family: Impact; font-size: 120%; text-align: center}
  13 </STYLE>
  14    </HEAD>
  15    <!--Copyright (c) 1996 Open Market, Inc.                                    -->
  16    <!--See the file "LICENSE" for information on usage and redistribution-->
  17    <!--of this file, and for a DISCLAIMER OF ALL WARRANTIES.                   -->
  18    <!-- $Id: fastcgi.htm,v 1.4 2002/02/25 00:45:06 robs Exp $ -->
  19    <BODY>
  20       <P>
  21          Open Market, Inc.
  22       </P>
  23       <P>
  24       </P>
  25       <DIV CLASS="c1">
  26          Technical White Paper<BR>
  27       </DIV>
  28       <H1>
  29          FastCGI:<BR>
  30           A High-Performance Web Server Interface
  31       </H1>
  32       <P>
  33          April 1996<!--Please send comments to:-->
  34       </P>
  35       <HR>
  36       <!-- payne@openmarket.com-->
  37       <H2>
  38          1. Introduction
  39       </H2>
  40       <P>
  41          The surge in the use of the Web by business has created a tremendous need for server extension applications
  42          that create dynamic content. These are the applications that will allow businesses to deliver products,
  43          services, and messages whose shape and content are in part determined by the interaction with, and knowledge
  44          of, the customers to which they are delivered.
  45       </P>
  46       <P>
  47          This important movement away from static Web content is pushing the limits and exposing the weaknesses of the
  48          environment in which these applications are currently bound: CGI (Common Gateway Interface). Most importantly
  49          it does not offer the performance these applications require. A new communication infrastructure is needed to
  50          connect Web servers with these new applications. This is what led Open Market to develop FastCGI.
  51       </P>
  52       <P>
  53          FastCGI is a fast, open, and secure Web server interface that solves the performance problems inherent in CGI,
  54          without introducing the overhead and complexity of proprietary APIs (Application Programming Interfaces).
  55       </P>
  56       <P>
  57          This paper assumes that the reader has basic familiarity with Web technology and developing Web applications.
  58       </P>
  59       <H3>
  60          Common Gateway Interface
  61       </H3>
  62       <P>
  63          The de facto standard interface for Web server applications is CGI, which was first implemented in the NCSA
  64          server. CGI has many benefits:
  65       </P>
  66       <UL>
  67          <LI>
  68             <B>Simplicity.</B> <SPAN>It is easy to understand.</SPAN>
  69          </LI>
  70          <LI>
  71             <B>Language independence.</B> CGI applications can be written in nearly any language.
  72          </LI>
  73          <LI>
  74             <B>Process isolation.</B> Since applications run in separate processes, buggy applications cannot crash the
  75             Web server or access the server&#39;s private internal state.
  76          </LI>
  77          <LI>
  78             <B>Open standard.</B> Some form of CGI has been implemented on every Web server.
  79          </LI>
  80          <LI>
  81             <B>Architecture independence.</B> CGI is not tied to any particular server architecture (single threaded,
  82             multi-threaded, etc.).
  83          </LI>
  84       </UL>
  85       <P>
  86          CGI also has some significant drawbacks. The leading problem is performance: Since a new process is created
  87          for each request and thrown away when the request is done, efficiency is poor.
  88       </P>
  89       <P>
  90          CGI also has limited functionality: It only supports a simple &quot;responder&quot; role, where the
  91          application generates the response that is returned to the client. CGI programs can&#39;t link into other
  92          stages of Web server request processing, such as authorization and logging.
  93       </P>
  94       <H3>
  95          Server APIs
  96       </H3>
  97       <P>
  98          In response to the performance problems for CGI, several vendors have developed APIs for their servers. The
  99          two most notable are NSAPI from Netscape and ISAPI from Microsoft. The freely available Apache server also has
 100          an API.
 101       </P>
 102       <P>
 103          Applications linked into the server API may be significantly faster than CGI programs. The CGI
 104          startup/initialization problem is improved, because the application runs in the server process and is
 105          persistent across requests. Web server APIs also offer more functionality than CGI: you can write extensions
 106          that perform access control, get access to the server&#39;s log file, and link in to other stages in the
 107          server&#39;s request processing.
 108       </P>
 109       <P>
 110          However, APIs sacrifice all of CGI&#39;s benefits. Vendor APIs have the following problems:
 111       </P>
 112       <UL>
 113          <LI>
 114             <B>Complexity.</B> Vendor APIs introduce a steep learning curve, with increased implementation and
 115             maintenance costs.
 116          </LI>
 117          <LI>
 118             <B>Language dependence.</B> Applications have to be written in a language supported by the vendor API
 119             (usually C/C++). Perl, the most popular language for CGI programs, can&#39;t be used with any existing
 120             vendor API.
 121          </LI>
 122          <LI>
 123             <B>No process isolation.</B> <SPAN>Since the applications run in the server&#39;s address space, buggy
 124             applications can corrupt the core server (or each other). A malicious or buggy application can compromise
 125             server security, and bugs in the core server can corrupt applications.</SPAN>
 126          </LI>
 127          <LI>
 128             <B>Proprietary.</B> Coding your application to a particular API locks you into a particular vendor&#39;s
 129             server.
 130          </LI>
 131          <LI>
 132             <B>Tie-in to server architecture.</B> API applications have to share the same architecture as the server:
 133             If the Web server is multi-threaded, the application has to be thread-safe. If the Web server has
 134             single-threaded processes, multi-threaded applications don&#39;t gain any performance advantage. Also, when
 135             the vendor changes the server&#39;s architecture, the API will usually have to change, and applications
 136             will have to be adapted or rewritten.
 137          </LI>
 138       </UL>
 139       <H3>
 140          FastCGI
 141       </H3>
 142       <P>
 143          The FastCGI interface combines the best aspects of CGI and vendor APIs. Like CGI, FastCGI applications run in
 144          separate, isolated processes. FastCGI&#39;s advantages include:
 145       </P>
 146       <UL>
 147          <LI>
 148             <B>Performance.</B> FastCGI processes are persistent-they are reused to handle multiple requests. This
 149             solves the CGI performance problem of creating new processes for each request.
 150          </LI>
 151          <LI>
 152             <B>Simplicity, with easy migration from CGI.</B> The FastCGI application library (described on page 9)
 153             simplifies the migration of existing CGI applications. Applications built with the application library can
 154             also run as CGI programs, for backward compatibility with old Web servers.
 155          </LI>
 156          <LI>
 157             <B>Language independence.</B> Like CGI, FastCGI applications can be written in any language, not just
 158             languages supported by the vendor API.
 159          </LI>
 160          <LI>
 161             <B>Process isolation.</B> A buggy FastCGI application cannot crash or corrupt the core server or other
 162             applications. A malicious FastCGI application cannot steal any secrets (such as session keys for
 163             encryption) from the Web server.
 164          </LI>
 165          <LI>
 166             <B>Non-proprietary.</B> FastCGI is supported in all of Open Market&#39;s server products, and support is
 167             under development for other Web servers, including the freely available Apache and NCSA servers, as well as
 168             commercial servers from Microsoft and Netscape.
 169          </LI>
 170          <LI>
 171             <B>Architecture independence.</B> The FastCGI interface is not tied to a particular server architecture.
 172             Any Web server can implement the FastCGI interface. Also, FastCGI does not impose any architecture on the
 173             application: applications can be single or multi-threaded, regardless of the threading architecture of the
 174             Web server.
 175          </LI>
 176          <LI>
 177             <B>Support for distributed computing.</B> FastCGI provides the ability to run applications remotely, which
 178             is useful for distributing load and managing external Web sites.
 179          </LI>
 180       </UL>
 181       <P>
 182          The following sections describe the FastCGI interface, protocol, application library, and support in Open
 183          Market&#39;s WebServer products.
 184       </P>
 185       <H2>
 186          2. FastCGI Interface
 187       </H2>
 188       <P>
 189          The functionality provided by the FastCGI interface is very similar to that provided by CGI. To best
 190          understand the FastCGI protocol, we review the CGI interface here. Basic CGI request processing proceeds as
 191          follows:
 192       </P>
 193       <OL>
 194          <LI>
 195             For each request, the server creates a new process and the process initializes itself.
 196          </LI>
 197          <LI>
 198             The Web server passes the request information (such as remote host, username, HTTP headers, etc.) to the
 199             CGI program in environment variables.
 200          </LI>
 201          <LI>
 202             The Web server sends any client input (such as user-entered field values from an HTML form) to the CGI
 203             program&#39;s standard input.
 204          </LI>
 205          <LI>
 206             The CGI program writes any output to be returned to the client on standard output. Error information
 207             written to standard error is logged by the Web server.
 208          </LI>
 209          <LI>
 210             When the CGI process exits, the request is complete.
 211          </LI>
 212       </OL>
 213       <P>
 214          FastCGI is conceptually very similar to CGI, with two major differences:
 215       </P>
 216       <UL>
 217          <LI>
 218             FastCGI processes are persistent: after finishing a request, they wait for a new request instead of
 219             exiting.
 220          </LI>
 221          <LI>
 222             Instead of using operating system environment variables and pipes, the FastCGI protocol multiplexes the
 223             environment information, standard input, output and error over a single full-duplex connection. This allows
 224             FastCGI programs to run on remote machines, using TCP connections between the Web server and the FastCGI
 225             application.
 226          </LI>
 227       </UL>
 228       <P>
 229          Request processing in a single-threaded FastCGI application proceeds as follows:
 230       </P>
 231       <OL>
 232          <LI>
 233             The Web server creates FastCGI application processes to handle requests. The processes may be created at
 234             startup, or created on demand.
 235          </LI>
 236          <LI>
 237             The FastCGI program initializes itself, and waits for a new connection from the Web server.
 238          </LI>
 239          <LI>
 240             When a client request comes in, the Web server opens a connection to the FastCGI process. The server sends
 241             the CGI environment variable information and standard input over the connection.
 242          </LI>
 243          <LI>
 244             The FastCGI process sends the standard output and error information back to the server over the same
 245             connection.
 246          </LI>
 247          <LI>
 248             When the FastCGI process closes the connection, the request is complete. The FastCGI process then waits for
 249             another connection from the Web server.
 250          </LI>
 251       </OL>
 252       <P>
 253          FastCGI applications can run locally (on the same machine as the Web server) or remotely. For local
 254          applications, the server uses a full-duplex pipe to connect to the FastCGI application process. For remote
 255          applications, the server uses a TCP connection.
 256       </P>
 257       <P>
 258          FastCGI applications can be single-threaded or multi-threaded. For single threaded applications, the Web
 259          server maintains a pool of processes (if the application is running locally) to handle client requests. The
 260          size of the pool is user configurable. Multi-threaded FastCGI applications may accept multiple connections
 261          from the Web server and handle them simultaneously in a single process. (For example, Java&#39;s built-in
 262          multi-threading, garbage collection, synchronization primitives, and platform independence make it a natural
 263          implementation language for multi-threaded FastCGI applications.)
 264       </P>
 265       <H3>
 266          Remote FastCGI
 267       </H3>
 268       <P>
 269          FastCGI&#39;s ability to run applications remotely (over a TCP connection) provides some major benefits. These
 270          benefits are described in this section, along with some of the security issues that affect remote FastCGI
 271          applications.
 272       </P>
 273       <H4>
 274          FastCGI with Firewalls
 275       </H4>
 276       <P>
 277          Applications that run on organizational (external) Web servers and depend on internal databases can be a
 278          challenge to administer. Figure 1 shows a typical organization, with an external Web server, a firewall
 279          restricting access to the internal network, and internal databases and applications.
 280       </P>
 281       <P>
 282       </P>
 283       <DIV CLASS="c2">
 284          <IMG ALT="error-file:TidyOut.log" SRC="img00001.gif"><A NAME="_Ref352505891">Figure 1</A>
 285       </DIV>
 286       <P>
 287          With CGI and vendor APIs, the application has to run on the Web server machine. This means the server
 288          administrator has to replicate the necessary database information onto the system hosting the Web server
 289          (which may be difficult to do in an automated way without compromising firewall security). Or, the
 290          administrator may build a &quot;bridge&quot; that allows access through the Web server to internal databases
 291          and applications (which is effectively re-inventing remote FastCGI).
 292       </P>
 293       <P>
 294          With remote FastCGI, the applications can run on the internal network, simplifying the administrator&#39;s
 295          job. When used with appropriate firewall configuration and auditing, this approach provides a secure,
 296          high-performance, scalable way to bring internal applications and data to the external network.
 297       </P>
 298       <H4>
 299          Load Distribution
 300       </H4>
 301       <P>
 302          For resource-intensive CGI and API applications, the Web server machine quickly becomes the bottleneck for
 303          overall throughput. The usual way to solve this performance problem is to buy a bigger, faster Web server
 304          machine, or to partition the Web site across several Web servers.
 305       </P>
 306       <P>
 307          With remote FastCGI, the resource-intensive applications can be moved off the Web server machine, giving the
 308          server administrator additional flexibility in configuring the Web server. The administrator can configure
 309          FastCGI applications &quot;behind the scenes&quot; without having to change any content links or the external
 310          view of the Web site. The administrator can use several smaller, inexpensive server machines for applications,
 311          and can tailor each machine to the application it is hosting.
 312       </P>
 313       <H4>
 314          Security Issues with Remote FastCGI
 315       </H4>
 316       <P>
 317          The two security issues with remote FastCGI connections are authentication and privacy. FastCGI applications
 318          should only accept connections from Web servers that they trust (the application library includes support for
 319          IP address validation). Future versions of the protocol will include support for applications authenticating
 320          Web servers, as well as support for running remote connections over secure transport protocols such as SSL or
 321          PCT.<!--This pargraph needs to be made stronger, going into the issues in a little more detail.-->
 322       </P>
 323       <H3>
 324          The FastCGI Protocol
 325       </H3>
 326       <P>
 327          This section offers a brief introduction to the protocol used on the connection between the Web server and
 328          FastCGI application. Most application developers will use the FastCGI application library and won&#39;t have
 329          to worry about the protocol details. However, specialized applications are free to implement the FastCGI
 330          protocol directly.
 331       </P>
 332       <P>
 333          FastCGI uses a simple packet record format on the connection between the application and the Web server. The
 334          same record format is used in both directions and is outlined in Figure 2.
 335       </P>
 336       <P>
 337       </P>
 338       <DIV CLASS="c2">
 339          <IMG ALT="error-file:TidyOut.log" SRC="img00002.gif"><A NAME="_Ref352404075">Figure 2</A>
 340       </DIV>
 341       <P>
 342          The protocol version field specifies the version of the FastCGI protocol that is in use. The type field
 343          specifies the type of the record (described in the following section). The request ID identifies this record
 344          to a particular request, allowing multiple requests to be multiplexed over a single connection. The data
 345          length field specifies the number of data bytes that follow.
 346       </P>
 347       <P>
 348          The different FastCGI packet types are:
 349       </P>
 350       <TABLE>
 351          <TR>
 352             <TD WIDTH="186">
 353                <TT CLASS="c3">FCGI_PARAMS</TT>
 354             </TD>
 355             <TD WIDTH="228">
 356                Used for sending name/value pairs (CGI environment variables) from the Web server to the application.
 357             </TD>
 358          </TR>
 359          <TR>
 360             <TD WIDTH="186">
 361                <TT CLASS="c3">FCGI_STDIN</TT>
 362             </TD>
 363             <TD WIDTH="228">
 364                Used for sending the standard input from the Web server to the application.
 365             </TD>
 366          </TR>
 367          <TR>
 368             <TD WIDTH="186">
 369                <TT CLASS="c3">FCGI_DATA</TT>
 370             </TD>
 371             <TD WIDTH="228">
 372                Used for sending filter data to the application (for more information, see the filter role described on
 373                page 7.)
 374             </TD>
 375          </TR>
 376          <TR>
 377             <TD WIDTH="186">
 378                <TT CLASS="c3">FCGI_STDOUT</TT>
 379             </TD>
 380             <TD WIDTH="228">
 381                Used to send standard output from the application to the Web server.
 382             </TD>
 383          </TR>
 384          <TR>
 385             <TD WIDTH="186">
 386                <TT CLASS="c3">FCGI_STDERR</TT>
 387             </TD>
 388             <TD WIDTH="228">
 389                Used to send standard error information from the application to the Web server.
 390             </TD>
 391          </TR>
 392          <TR>
 393             <TD WIDTH="186">
 394                <TT CLASS="c3">FCGI_END_REQUEST</TT>
 395             </TD>
 396             <TD WIDTH="228">
 397                Ends the request (can be sent by either the server or the application).
 398             </TD>
 399          </TR>
 400       </TABLE>
 401       <P>
 402       </P>
 403       <P>
 404          For complete protocol details, see the <I>FastCGI Protocol Specification</I>, available from the Web site
 405          listed at the end of this paper.
 406       </P>
 407       <H2>
 408          3. Application Roles
 409       </H2>
 410       <P>
 411          A major problem with CGI is its limited functionality: CGI programs can only provide simple responses to
 412          requests. FastCGI provides expanded functionality with support for three different application
 413          &quot;roles&quot;:
 414       </P>
 415       <UL>
 416          <LI>
 417             <B>Responder.</B> This is the basic FastCGI role, and corresponds to the simple functionality offered by
 418             CGI today.
 419          </LI>
 420          <LI>
 421             <B>Filter.</B> The FastCGI application filters the requested Web server file before sending it to the
 422             client.
 423          </LI>
 424          <LI>
 425             <B>Authorizer.</B> The FastCGI program performs an access control decision for the request (such as
 426             performing a username/password database lookup).
 427          </LI>
 428       </UL>
 429       <P>
 430          Other roles will be defined in the future. For instance, a &quot;logger&quot; role would be useful, where the
 431          FastCGI program would receive the server&#39;s log entries for real-time processing and analysis.
 432       </P>
 433       <P>
 434          The roles are described in more detail in the following sections.
 435       </P>
 436       <H3>
 437          Responder Role
 438       </H3>
 439       <P>
 440          FastCGI&#39;s Responder role is identical to the functionality provided by CGI today. When a request comes
 441          into the server, the FastCGI program generates the response that&#39;s returned to the client (typically an
 442          HTML page).
 443       </P>
 444       <H3>
 445          <A NAME="_Ref352404524">Filter Role</A>
 446       </H3>
 447       <P>
 448          The Filter role allows a FastCGI application to process a requested file before it is returned to the client.
 449       </P>
 450       <P>
 451          Let&#39;s assume that the Web server is configured so that all files with the .<TT CLASS="c3">sgml</TT>
 452          extension are processed by a SGML-to-HTML FastCGI filter application, and the user accesses the following URL:
 453       </P>
 454       <P>
 455          <TT CLASS="c3">/document.sgml</TT>
 456       </P>
 457       <P>
 458          After the Web server makes an access control decision and maps this URL to a content file, it invokes the
 459          FastCGI filter application with this file available as input. The FastCGI program&#39;s HTML output is sent
 460          back to the client, just as in the responder role. The process is outlined in Figure 3.
 461       </P>
 462       <P>
 463       </P>
 464       <DIV CLASS="c2">
 465          <IMG ALT="error-file:TidyOut.log" SRC="img00003.gif"><A NAME="_Ref352560526">Figure 3</A>
 466       </DIV>
 467       <P>
 468          Filter applications can significantly improve performance by caching filter results (the server provides the
 469          modification time in the request information so that applications can flush the cache when the server file has
 470          been modified).
 471       </P>
 472       <P>
 473          The Filter role is useful for:
 474       </P>
 475       <UL>
 476          <LI>
 477             On-the-fly format conversions
 478          </LI>
 479          <LI>
 480             Dynamic documents (such as documents with embedded SQL queries, or dynamic advertisement insertion)
 481          </LI>
 482          <LI>
 483             Applying a standard template: headers, footers, and backgrounds
 484          </LI>
 485       </UL>
 486       <H3>
 487          Authorizer Role
 488       </H3>
 489       <P>
 490          The Authorizer role allows a FastCGI application to make an access control decision for a request. The FastCGI
 491          application is invoked with all of the request information, just as in the Responder role. If the authorizer
 492          application generates a &quot;200 OK&quot; HTTP result, the Web server assumes that access is allowed and
 493          proceeds with the request. (The Web server may process other access checks, including other FastCGI
 494          authorizers, before access is ultimately allowed.) If the application generates any other response, that
 495          response is returned to the client and the request is ended. The response can be any valid HTTP response,
 496          including &quot;Access Denied&quot; or &quot;Redirect&quot;.
 497       </P>
 498       <P>
 499          The Authorizer role is useful for:
 500       </P>
 501       <UL>
 502          <LI>
 503             Access control based on username and password, where the user information is looked up in an external
 504             database.
 505          </LI>
 506          <LI>
 507             Complex access policies, such as time-of-day based access.
 508          </LI>
 509          <LI>
 510             Smart-card challenge/response authentication.
 511          </LI>
 512          <LI>
 513             Dynamic redirects, where the user is sent to different pages based on the request profile.
 514          </LI>
 515       </UL>
 516       <H2>
 517          <A NAME="_Ref352251764">4. FastCGI Application Library</A>
 518       </H2>
 519       <P>
 520          Open Market has developed a FastCGI application library that implements the FastCGI protocol (hiding the
 521          protocol details from the developer). This library makes implementing FastCGI programs as easy as writing CGI
 522          applications.
 523       </P>
 524       <P>
 525          The application library provides a replacement for the C language standard I/O (stdio) routines, such as <TT
 526          CLASS="c3">printf()</TT> and <TT CLASS="c3">gets()</TT>. The library converts references to standard input,
 527          standard output, and standard error to the FastCGI protocol. References to other files &quot;fall
 528          through&quot; to the underlying operating system standard I/O routines.
 529       </P>
 530       <P>
 531          This approach has several benefits:
 532       </P>
 533       <UL>
 534          <LI>
 535             Developers don&#39;t have to learn a new API to develop FastCGI applications.
 536          </LI>
 537          <LI>
 538             Existing CGI programs can be migrated with minimal source changes (CGI migration is described in more
 539             detail in the following section).
 540          </LI>
 541          <LI>
 542             FastCGI interpreters for Perl, Tcl, and other interpreted languages can be built without modifying the
 543             interpreter source code.
 544          </LI>
 545       </UL>
 546       <P>
 547          Here&#39;s a simple FastCGI application:
 548       </P>
 549       <BR>
 550       <BR>
 551 <PRE>
 552     #include &lt;fcgi_stdio.h&gt;
 553
 554     void main(void)
 555     {
 556         int count = 0;
 557         while(FCGI_Accept() &gt;= 0) {
 558             printf(&quot;Content-type: text/html\r\n&quot;);
 559             printf(&quot;\r\n&quot;);
 560             printf(&quot;Hello world!&lt;br&gt;\r\n&quot;);
 561             printf(&quot;Request number %d.&quot;, count++);
 562         }
 563         exit(0);
 564     }
 565 </PRE>
 566       <P>
 567          This application returns a &quot;Hello world&quot; HTML response to the client. It also keeps a counter of the
 568          number of times it has been accessed, displaying the value of the counter at each request.
 569       </P>
 570       <P>
 571          The <TT>fcgi_stdio.h</TT> header file provides the FastCGI replacement routines for the C standard I/O
 572          library. The <TT>FCGI_Accept()</TT> routine accepts a new request from the Web server.
 573       </P>
 574       <H3>
 575          Migrating Existing CGI Programs
 576       </H3>
 577       <P>
 578          The application library was designed to make migration of existing CGI programs as simple as possible. Many
 579          applications can be converted by adding a loop around the main request processing code and recompiling with
 580          the FastCGI application library. FastCGI applications have the following structure, with an initialization
 581          section and a request processing loop:
 582       </P>
 583       <P>
 584          <I>Initialize application;<BR>
 585          </I> <TT>while(FCGI_Accept() &gt;= 0) {</TT><BR>
 586           <I>Process request</I>;<BR>
 587           <TT>}</TT>
 588       </P>
 589       <P>
 590          To ease migration to FastCGI, executables built with the application library can run as either CGI or FastCGI
 591          programs, depending on how they are invoked. The library detects the execution environment and automatically
 592          selects FastCGI or regular I/O routines, as appropriate.
 593       </P>
 594       <P>
 595          After migration, developers can clean up their FastCGI applications for best performance:
 596       </P>
 597       <UL>
 598          <LI>
 599             Fix any resource leaks. Many CGI programs do not attempt to manage memory or close files, because they
 600             assume the world is going to be cleaned up when they exit. (If you don&#39;t want to clean up your program,
 601             you can just have your process assume that it is leaking memory and exit after processing some fixed number
 602             of requests.) Purify from Pure Software is one of a number of excellent tools for finding leaks and other
 603             memory use problems.
 604          </LI>
 605          <LI>
 606             Fix any problems with retained application state. The application must ensure that any state that it
 607             creates in processing one request has no unintended effects on later requests.
 608          </LI>
 609          <LI>
 610             Collapse functionality. A common practice with CGI applications is to implement many small programs, with
 611             one function per program. CGI encourages this, because smaller programs load faster. With FastCGI, it&#39;s
 612             better to have related functionality in a single executable, so there are fewer processes to manage and
 613             applications can take advantage of sharing cached information across functions.
 614          </LI>
 615       </UL>
 616       <P>
 617          Applications written in Perl, Tcl, and other scripting languages can be migrated by using a language
 618          interpreter built with the application library. FastCGI-integrated Tcl and Perl interpreters for popular Unix
 619          platforms are available from Open Market. The interpreters are backward-compatible: They can run standard Tcl
 620          and Perl applications.
 621       </P>
 622       <H2>
 623          5. FastCGI in the Open Market WebServer
 624       </H2>
 625       <P>
 626          This section describes the FastCGI support in the following Open Market server products:
 627       </P>
 628       <UL>
 629          <LI>
 630             Open Market WebServer V2.0
 631          </LI>
 632          <LI>
 633             Open Market Secure WebServer V2.0
 634          </LI>
 635          <LI>
 636             Open Market Secure WebServer (Global) V2.0
 637          </LI>
 638       </UL>
 639       <P>
 640          For more information about FastCGI support, see the <I>Open Market WebServer Installation and Configuration
 641          Guide</I>.
 642       </P>
 643       <H3>
 644          Server Configuration
 645       </H3>
 646       <P>
 647          FastCGI applications are configured with the server&#39;s configuration file. Configuration has two parts.
 648       </P>
 649       <P>
 650          First, the server administrator defines an <I>application class</I>. For local applications, the application
 651          class specifies the details of running the FastCGI application, such as:
 652       </P>
 653       <UL>
 654          <LI>
 655             The pathname of the application executable.
 656          </LI>
 657          <LI>
 658             Any arguments and environment variables to pass to the process at startup.
 659          </LI>
 660          <LI>
 661             The number of processes to run.
 662          </LI>
 663       </UL>
 664       <P>
 665          For remote applications, the class configuration information includes the host and TCP port to connect to. The
 666          Web server assumes that the FastCGI application has been started on the remote host. If a request comes in and
 667          the server can&#39;t connect to the FastCGI TCP port, the server logs an error and returns an error page to
 668          the client.
 669       </P>
 670       <P>
 671          The second configuration step is mapping the application class to a role:
 672       </P>
 673       <UL>
 674          <LI>
 675             For responder roles, the administrator configures some part of the URL space to be handled by the FastCGI
 676             application. For example, all URLs beginning with <SPAN CLASS="c4">/rollcall/</SPAN> might be handled by
 677             the employee database application.
 678          </LI>
 679          <LI>
 680             For filter roles, the administrator configures a file extension to be handled by a filter application. For
 681             example, all files with the <SPAN CLASS="c4">.sql</SPAN> extension could be handled by a SQL query lookup
 682             filter.
 683          </LI>
 684          <LI>
 685             For authorizer roles, the administrator configures an authorizer application in the same manner as other
 686             access methods (hostname, username/password, etc.) A request must pass <I>all</I> access control checks
 687             (possibly including multiple FastCGI authorizers) before access is allowed.
 688          </LI>
 689       </UL>
 690       <H3>
 691          Basic FastCGI
 692       </H3>
 693       <P>
 694          To simplify migration for existing CGI programs, the WebServer provides a simple way to install new FastCGI
 695          programs without having to reconfigure the server. However, this approach doesn&#39;t offer all of the
 696          performance benefits of FastCGI application classes.
 697       </P>
 698       <P>
 699          The WebServer treats any file with the extension <SPAN CLASS="c4">.fcg</SPAN> as a FastCGI application. When a
 700          request corresponds to such a file, the WebServer creates a new FastCGI process to handle the request, and
 701          shuts down the process when the request is complete (just as in CGI). In this mode of operation performance is
 702          comparable to CGI. Future versions of the WebServer will improve performance by automatically caching
 703          processes and re-using them for subsequent requests.
 704       </P>
 705       <H3>
 706          Session Affinity
 707       </H3>
 708       <P>
 709          FastCGI programs can improve performance by caching information in the application process. For applications
 710          that require frequent but expensive operations such as validating a username/password in an external database
 711          for each request, this technique can significantly improve performance.
 712       </P>
 713       <P>
 714          To improve the effectiveness of this technique, the WebServer implements <I>session affinity</I>. When session
 715          affinity is enabled, the WebServer arranges for all requests in a user session to be handled by the same
 716          FastCGI application process. What constitutes a &quot;session&quot; is configurable. The default configuration
 717          uses the WebServer&#39;s built-in session tracking facility to identify user sessions. However, the server
 718          administrator can use any part of the request information for the session affinity mapping: the URL path, the
 719          client&#39;s hostname, the username, etc.
 720          <!--Talk about applications that need to hold onto resources for the user (such as open connections to the database).-->
 721       </P>
 722       <H2>
 723          6. FastCGI Performance Analysis
 724       </H2>
 725       <P>
 726          How fast is FastCGI? The answer depends on the application. This section contains some real FastCGI
 727          performance measurements, as well as guidelines for estimating the FastCGI speedup.
 728       </P>
 729       <H3>
 730          FastCGI vs CGI
 731       </H3>
 732       <P>
 733          We measured the relative performance of CGI, FastCGI, and static files on the Open Market WebServer, using a
 734          simple application that generates a fixed number of output bytes. The following table shows the measured
 735          request processing time for different request types on a typical platform. The times are measured from the
 736          client perspective and include client, server, and application processing time.
 737       </P>
 738       <TABLE BORDERCOLOR="#000000" BORDER="2">
 739          <TR>
 740             <TD WIDTH="72">
 741                <DIV CLASS="c5">
 742                   Static file
 743                </DIV>
 744             </TD>
 745             <TD WIDTH="180">
 746                <DIV CLASS="c5">
 747                   21ms + 0.19ms per Kbyte
 748                </DIV>
 749             </TD>
 750          </TR>
 751          <TR>
 752             <TD WIDTH="72">
 753                <DIV CLASS="c5">
 754                   FastCGI
 755                </DIV>
 756             </TD>
 757             <TD WIDTH="180">
 758                <DIV CLASS="c5">
 759                   22ms + 0.28ms per Kbyte
 760                </DIV>
 761             </TD>
 762          </TR>
 763          <TR>
 764             <TD WIDTH="72">
 765                <DIV CLASS="c5">
 766                   CGI
 767                </DIV>
 768             </TD>
 769             <TD WIDTH="180">
 770                <DIV CLASS="c5">
 771                   59ms + 0.37ms per Kbyte
 772                </DIV>
 773             </TD>
 774          </TR>
 775       </TABLE>
 776       <P>
 777          FastCGI performance is comparable to serving static files, and significantly better than CGI (clearly showing
 778          the high overhead for process creation). Real applications have an additional time component: process
 779          initialization, which should be added to overall request processing time.
 780       </P>
 781       <P>
 782          Let&#39;s use this data to estimate the speedup from migrating a typical database CGI application to FastCGI.
 783          Assume the application takes 50ms to initialize the database connection and generates 5K of output data.
 784          Request performance can be computed as follows:
 785       </P>
 786       <TABLE>
 787          <TR>
 788             <TD WIDTH="108">
 789                CGI
 790             </TD>
 791             <TD WIDTH="331">
 792                59ms + 50ms + (0.37ms)(5) = 111ms
 793             </TD>
 794          </TR>
 795          <TR>
 796             <TD WIDTH="108">
 797                FastCGI
 798             </TD>
 799             <TD WIDTH="331">
 800                22ms + (0.28ms)(5) = 23ms
 801             </TD>
 802          </TR>
 803       </TABLE>
 804       <P>
 805          In this example, FastCGI has a 5x performance advantage over CGI, mostly due to savings from not having to
 806          create and initialize new processes for each request.<!--Need to talk about FastCGI vs proprietary APIs.-->
 807       </P>
 808       <H2>
 809          7. Conclusions
 810       </H2>
 811       <P>
 812          Today&#39;s Web business applications need a platform that&#39;s fast, open, maintainable, straightforward,
 813          stable, and secure. FastCGI&#39;s design meets these requirements, and provides for a logical extension from
 814          proven and widely deployed CGI technology. This allows developers to take advantage of FastCGI&#39;s benefits
 815          without losing their existing investment in CGI applications.<!--Need to talk about NT.-->
 816
 817          <!--Need to give &quot;more punch&quot; to this conclusion: include info about uses for FastCGI (accessing legacy data in databases, access control, distributed applications, apps that have to run in multiple OS environments. -->
 818       </P>
 819       <H2>
 820          8. For More Information
 821       </H2>
 822       <P>
 823          For more information about Open Market and our products, visit our Web site at:<SPAN CLASS=
 824          "c4">http://www.openmarket.com/</SPAN>
 825       </P>
 826       <P>
 827          For more information about the FastCGI protocol and the developer&#39;s kit, and the latest information about
 828          FastCGI standardization and support in other Web servers, visit the FastCGI project page at:<SPAN CLASS=
 829          "c4">http://www.openmarket.com/fastcgi/</SPAN>
 830       </P>
 831    </BODY>
 832 </HTML>
 833