-<HTML>\r
-\r
-<HEAD>\r
-\r
-<TITLE>FastCGI</TITLE>\r
-\r
-<META NAME="GENERATOR" CONTENT="Internet Assistant for Microsoft Word 2.0z">\r
+<HTML>
+
+
+
+<HEAD>
+
+
+
+<TITLE>FastCGI</TITLE>
+
+
+
+<META NAME="GENERATOR" CONTENT="Internet Assistant for Microsoft Word 2.0z">
+
</HEAD>
<!--Copyright (c) 1996 Open Market, Inc. -->
<!--See the file "LICENSE.TERMS" for information on usage and redistribution-->
<!--of this file, and for a DISCLAIMER OF ALL WARRANTIES. -->
-<!-- $Id: fastcgi.htm,v 1.1 1997/09/16 15:36:27 stanleyg Exp $ -->
-
-<BODY>\r
-\r
-<P>\r
-Open Market, Inc.</FONT>\r
-<P>\r
-<CENTER><FONT SIZE=4 COLOR=#FFFFFF FACE="Impact">Technical White\r
-Paper<BR>\r
-</FONT></CENTER>\r
-<H1>FastCGI:<BR>\r
-A High-Performance Web Server Interface</H1>\r
-\r
-<P>\r
-April 1996<!--Please send comments to:--></FONT>\r
-<HR>\r
-<!-- payne@openmarket.com-->\r
-<H2>1. Introduction</H2>\r
-\r
-<P>\r
-The surge in the use of the Web by business has created\r
-a tremendous need for server extension applications that create\r
-dynamic content. These are the applications that will allow businesses\r
-to deliver products, services, and messages whose shape and content\r
-are in part determined by the interaction with, and knowledge\r
-of, the customers to which they are delivered.</FONT>\r
-<P>\r
-This important movement away from static Web content\r
-is pushing the limits and exposing the weaknesses of the environment\r
-in which these applications are currently bound: CGI (Common Gateway\r
-Interface). Most importantly it does not offer the performance\r
-these applications require. A new communication infrastructure\r
-is needed to connect Web servers with these new applications.\r
-This is what led Open Market to develop FastCGI.</FONT>\r
-<P>\r
-FastCGI is a fast, open, and secure Web server interface\r
-that solves the performance problems inherent in CGI, without\r
-introducing the overhead and complexity of proprietary APIs (Application\r
-Programming Interfaces). </FONT>\r
-<P>\r
-This paper assumes that the reader has basic familiarity\r
-with Web technology and developing Web applications.</FONT>\r
-<H3>Common Gateway Interface</H3>\r
-\r
-<P>\r
-The de facto standard interface for Web server applications\r
-is CGI, which was first implemented in the NCSA server. CGI has\r
-many benefits: </FONT>\r
-<UL>\r
-<LI><B>Simplicity. </FONT></B><FONT>It is\r
-easy to understand.</FONT>\r
-<LI><B>Language independence.</FONT></B>\r
-CGI applications can be written in nearly any language.</FONT>\r
-<LI><B>Process isolation.</FONT></B>\r
-Since applications run in separate processes, buggy applications\r
-cannot crash the Web server or access the server's private internal\r
-state.</FONT>\r
-<LI><B>Open standard.</FONT></B> Some\r
-form of CGI has been implemented on every Web server.</FONT>\r
-<LI><B>Architecture independence.</FONT></B>\r
-CGI is not tied to any particular server architecture (single\r
-threaded, multi-threaded, etc.).</FONT>\r
-</UL>\r
-\r
-<P>\r
-CGI also has some significant drawbacks. The leading\r
-problem is performance: Since a new process is created for each\r
-request and thrown away when the request is done, efficiency is\r
-poor.</FONT>\r
-<P>\r
-CGI also has limited functionality: It only supports\r
-a simple "responder" role, where the application generates\r
-the response that is returned to the client. CGI programs can't\r
-link into other stages of Web server request processing, such\r
-as authorization and logging.</FONT>\r
-<H3>Server APIs</H3>\r
-\r
-<P>\r
-In response to the performance problems for CGI,\r
-several vendors have developed APIs for their servers. The two\r
-most notable are NSAPI from Netscape and ISAPI from Microsoft.\r
- The freely available Apache server also has an API.</FONT>\r
-<P>\r
-Applications linked into the server API may be significantly\r
-faster than CGI programs. The CGI startup/initialization problem\r
-is improved, because the application runs in the server process\r
-and is persistent across requests. Web server APIs also offer\r
-more functionality than CGI: you can write extensions that perform\r
-access control, get access to the server's log file, and link\r
-in to other stages in the server's request processing.</FONT>\r
-<P>\r
-However, APIs sacrifice all of CGI's benefits. Vendor\r
-APIs have the following problems:</FONT>\r
-<UL>\r
-<LI><B>Complexity.</FONT></B> Vendor\r
-APIs introduce a steep learning curve, with increased implementation\r
-and maintenance costs.</FONT>\r
-<LI><B>Language dependence.</FONT></B>\r
- Applications have to be written in a language supported by the\r
-vendor API (usually C/C++). Perl, the most popular language for\r
-CGI programs, can't be used with any existing vendor API.</FONT>\r
-<LI><B>No process isolation. </FONT></B><FONT>Since\r
-the applications run in the server's address space, buggy applications\r
-can corrupt the core server (or each other). A malicious or buggy\r
-application can compromise server security, and bugs in the core\r
-server can corrupt applications.</FONT>\r
-<LI><B>Proprietary.</FONT></B> Coding\r
-your application to a particular API locks you into a particular\r
-vendor's server.</FONT>\r
-<LI><B>Tie-in to server architecture.</FONT></B>\r
- API applications have to share the same architecture as the server:\r
- If the Web server is multi-threaded, the application has to be\r
-thread-safe. If the Web server has single-threaded processes,\r
-multi-threaded applications don't gain any performance advantage.\r
- Also, when the vendor changes the server's architecture, the\r
-API will usually have to change, and applications will have to\r
-be adapted or rewritten.</FONT>\r
-</UL>\r
-\r
-<H3>FastCGI</H3>\r
-\r
-<P>\r
-The FastCGI interface combines the best aspects of\r
-CGI and vendor APIs. Like CGI, FastCGI applications run in separate,\r
-isolated processes. FastCGI's advantages include:</FONT>\r
-<UL>\r
-<LI><B>Performance.</FONT></B> FastCGI\r
-processes are persistent-they are reused to handle multiple requests.\r
- This solves the CGI performance problem of creating new processes\r
-for each request.</FONT>\r
-<LI><B>Simplicity, with easy migration from CGI.</FONT></B>\r
- The FastCGI application library (described on page 9) simplifies\r
-the migration of existing CGI applications. Applications built\r
-with the application library can also run as CGI programs, for\r
-backward compatibility with old Web servers.</FONT>\r
-<LI><B>Language independence.</FONT></B>\r
-Like CGI, FastCGI applications can be written in any language,\r
-not just languages supported by the vendor API.</FONT>\r
-<LI><B>Process isolation.</FONT></B>\r
-A buggy FastCGI application cannot crash or corrupt the core server\r
-or other applications. A malicious FastCGI application cannot\r
-steal any secrets (such as session keys for encryption) from the\r
-Web server.</FONT>\r
-<LI><B>Non-proprietary.</FONT></B> \r
-FastCGI is supported in all of Open Market's server products,\r
-and support is under development for other Web servers, including\r
-the freely available Apache and NCSA servers, as well as commercial\r
-servers from Microsoft and Netscape.</FONT>\r
-<LI><B>Architecture independence.</FONT></B>\r
- The FastCGI interface is not tied to a particular server architecture.\r
- Any Web server can implement the FastCGI interface. Also, FastCGI\r
-does not impose any architecture on the application: applications\r
-can be single or multi-threaded, regardless of the threading architecture\r
-of the Web server.</FONT>\r
-<LI><B>Support for distributed computing.</FONT></B>\r
- FastCGI provides the ability to run applications remotely, which\r
-is useful for distributing load and managing external Web sites.</FONT>\r
-</UL>\r
-\r
-<P>\r
-The following sections describe the FastCGI interface,\r
-protocol, application library, and support in Open Market's WebServer\r
-products.</FONT>\r
-<H2>2. FastCGI Interface</H2>\r
-\r
-<P>\r
-The functionality provided by the FastCGI interface\r
-is very similar to that provided by CGI. To best understand the\r
-FastCGI protocol, we review the CGI interface here. Basic CGI\r
-request processing proceeds as follows:</FONT>\r
-<OL>\r
-<LI>For each request, the server creates a new process\r
-and the process initializes itself.</FONT>\r
-<LI>The Web server passes the request information\r
-(such as remote host, username, HTTP headers, etc.) to the CGI\r
-program in environment variables.</FONT>\r
-<LI>The Web server sends any client input (such as\r
-user-entered field values from an HTML form) to the CGI program's\r
-standard input.</FONT>\r
-<LI>The CGI program writes any output to be returned\r
-to the client on standard output. Error information written to\r
-standard error is logged by the Web server.</FONT>\r
-<LI>When the CGI process exits, the request is complete.</FONT>\r
-</OL>\r
-\r
-<P>\r
-FastCGI is conceptually very similar to CGI, with\r
-two major differences:</FONT>\r
-<UL>\r
-<LI>FastCGI processes are persistent: after finishing\r
-a request, they wait for a new request instead of exiting.</FONT>\r
-<LI>Instead of using operating system environment\r
-variables and pipes, the FastCGI protocol multiplexes the environment\r
-information, standard input, output and error over a single full-duplex\r
-connection. This allows FastCGI programs to run on remote machines,\r
-using TCP connections between the Web server and the FastCGI application.</FONT>\r
-</UL>\r
-\r
-<P>\r
-Request processing in a single-threaded FastCGI application\r
-proceeds as follows:</FONT>\r
-<OL>\r
-<LI>The Web server creates FastCGI application processes\r
-to handle requests. The processes may be created at startup,\r
-or created on demand.</FONT>\r
-<LI>The FastCGI program initializes itself, and waits\r
-for a new connection from the Web server.</FONT>\r
-<LI>When a client request comes in, the Web server\r
-opens a connection to the FastCGI process. The server sends the\r
-CGI environment variable information and standard input over the\r
-connection.</FONT>\r
-<LI>The FastCGI process sends the standard output\r
-and error information back to the server over the same connection.</FONT>\r
-<LI>When the FastCGI process closes the connection,\r
-the request is complete. The FastCGI process then waits for another\r
-connection from the Web server.</FONT>\r
-</OL>\r
-\r
-<P>\r
-FastCGI applications can run locally (on the same\r
-machine as the Web server) or remotely. For local applications,\r
-the server uses a full-duplex pipe to connect to the FastCGI application\r
-process. For remote applications, the server uses a TCP connection.</FONT>\r
-<P>\r
-FastCGI applications can be single-threaded or multi-threaded.\r
- For single threaded applications, the Web server maintains a\r
-pool of processes (if the application is running locally) to\r
-handle client requests. The size of the pool is user configurable.\r
- Multi-threaded FastCGI applications may accept multiple connections\r
-from the Web server and handle them simultaneously in a single\r
-process. (For example, Java's built-in multi-threading, garbage\r
-collection, synchronization primitives, and platform independence\r
-make it a natural implementation language for multi-threaded FastCGI\r
-applications.)</FONT>\r
-<H3>Remote FastCGI</H3>\r
-\r
-<P>\r
-FastCGI's ability to run applications remotely (over\r
-a TCP connection) provides some major benefits. These benefits\r
-are described in this section, along with some of the security\r
-issues that affect remote FastCGI applications.</FONT>\r
-<H4>FastCGI with Firewalls</H4>\r
-\r
-<P>\r
-Applications that run on organizational (external) Web servers\r
-and depend on internal databases can be a challenge to administer.\r
-Figure 1 shows a typical organization, with an external Web server,\r
-a firewall restricting access to the internal network, and internal\r
-databases and applications.\r
-<P>\r
-<CENTER><IMG SRC="img00001.gif"><A NAME="_Ref352505891">Figure\r
-1</A></CENTER>\r
-<P>\r
-With CGI and vendor APIs, the application has to run on the Web\r
-server machine. This means the server administrator has to replicate\r
-the necessary database information onto the system hosting the\r
-Web server (which may be difficult to do in an automated way without\r
-compromising firewall security). Or, the administrator may build\r
-a "bridge" that allows access through the Web server\r
-to internal databases and applications (which is effectively re-inventing\r
-remote FastCGI).\r
-<P>\r
-With remote FastCGI, the applications can run on the internal\r
-network, simplifying the administrator's job. When used with\r
-appropriate firewall configuration and auditing, this approach\r
-provides a secure, high-performance, scalable way to bring internal\r
-applications and data to the external network.\r
-<H4>Load Distribution</H4>\r
-\r
-<P>\r
-For resource-intensive CGI and API applications, the Web server\r
-machine quickly becomes the bottleneck for overall throughput.\r
-The usual way to solve this performance problem is to buy a bigger,\r
-faster Web server machine, or to partition the Web site across\r
-several Web servers.\r
-<P>\r
-With remote FastCGI, the resource-intensive applications can be\r
-moved off the Web server machine, giving the server administrator\r
-additional flexibility in configuring the Web server. The administrator\r
-can configure FastCGI applications "behind the scenes"\r
-without having to change any content links or the external view\r
-of the Web site. The administrator can use several smaller, inexpensive\r
-server machines for applications, and can tailor each machine\r
-to the application it is hosting.\r
-<H4>Security Issues with Remote FastCGI</H4>\r
-\r
-<P>\r
-The two security issues with remote FastCGI connections are authentication\r
-and privacy. FastCGI applications should only accept connections\r
-from Web servers that they trust (the application library includes\r
-support for IP address validation). Future versions of the protocol\r
-will include support for applications authenticating Web servers,\r
-as well as support for running remote connections over secure\r
-transport protocols such as SSL or PCT.<!--This pargraph needs to be made stronger, going into the issues in a little more detail.-->\r
-\r
-<H3>The FastCGI Protocol</H3>\r
-\r
-<P>\r
-This section offers a brief introduction to the protocol\r
-used on the connection between the Web server and FastCGI application.\r
- Most application developers will use the FastCGI application\r
-library and won't have to worry about the protocol details. However,\r
-specialized applications are free to implement the FastCGI protocol\r
-directly.</FONT>\r
-<P>\r
-FastCGI uses a simple packet record format on the\r
-connection between the application and the Web server. The same\r
-record format is used in both directions and is outlined in Figure 2.</FONT>\r
-<P>\r
-<CENTER><IMG SRC="img00002.gif"><A NAME="_Ref352404075">Figure\r
-2</FONT></A></CENTER>\r
-<P>\r
-The protocol version field specifies the version\r
-of the FastCGI protocol that is in use. The type field specifies\r
-the type of the record (described in the following section). \r
-The request ID identifies this record to a particular request,\r
-allowing multiple requests to be multiplexed over a single connection.\r
- The data length field specifies the number of data bytes that\r
-follow.</FONT>\r
-<P>\r
-The different FastCGI packet types are:</FONT>\r
-<TABLE>\r
-\r
-<TR><TD WIDTH=186><TT><FONT FACE="Courier">FCGI_PARAMS</FONT></TT>\r
-</TD><TD WIDTH=228>Used for sending name/value pairs (CGI environment variables) from the Web server to the application.\r
-</TD></TR>\r
-\r
-<TR><TD WIDTH=186><TT><FONT FACE="Courier">FCGI_STDIN</FONT></TT>\r
-</TD><TD WIDTH=228>Used for sending the standard input from the Web server to the application.\r
-</TD></TR>\r
-\r
-<TR><TD WIDTH=186><TT><FONT FACE="Courier">FCGI_DATA</FONT></TT>\r
-</TD><TD WIDTH=228>Used for sending filter data to the application (for more information, see the filter role described on page 7.)\r
-</TD></TR>\r
-\r
-<TR><TD WIDTH=186><TT><FONT FACE="Courier">FCGI_STDOUT</FONT></TT>\r
-</TD><TD WIDTH=228>Used to send standard output from the application to the Web server.\r
-</TD></TR>\r
-\r
-<TR><TD WIDTH=186><TT><FONT FACE="Courier">FCGI_STDERR</FONT></TT>\r
-</TD><TD WIDTH=228>Used to send standard error information from the application to the Web server.\r
-</TD></TR>\r
-\r
-<TR><TD WIDTH=186><TT><FONT FACE="Courier">FCGI_END_REQUEST</FONT></TT>\r
-</TD><TD WIDTH=228>Ends the request (can be sent by either the server or the application).\r
-</TD></TR>\r
-\r
-</TABLE>\r
-\r
-<P>\r
-\r
-<P>\r
-For complete protocol details, see the <I>FastCGI Protocol Specification</I>,\r
-available from the Web site listed at the end of this paper.\r
-<H2>3. Application Roles</H2>\r
-\r
-<P>\r
-A major problem with CGI is its limited functionality:\r
- CGI programs can only provide simple responses to requests. \r
-FastCGI provides expanded functionality with support for three\r
-different application "roles":</FONT>\r
-<UL>\r
-<LI><B>Responder.</FONT></B> This is\r
-the basic FastCGI role, and corresponds to the simple functionality\r
-offered by CGI today.</FONT>\r
-<LI><B>Filter.</FONT></B> The FastCGI\r
-application filters the requested Web server file before sending\r
-it to the client.</FONT>\r
-<LI><B>Authorizer.</FONT></B> The FastCGI\r
-program performs an access control decision for the request (such\r
-as performing a username/password database lookup). </FONT>\r
-</UL>\r
-\r
-<P>\r
-Other roles will be defined in the future. For instance,\r
-a "logger" role would be useful, where the FastCGI program\r
-would receive the server's log entries for real-time processing\r
-and analysis.</FONT>\r
-<P>\r
-The roles are described in more detail in the following\r
-sections.</FONT>\r
-<H3>Responder Role</H3>\r
-\r
-<P>\r
-FastCGI's Responder role is identical to the functionality\r
-provided by CGI today. When a request comes into the server,\r
-the FastCGI program generates the response that's returned to\r
-the client (typically an HTML page).</FONT>\r
-<H3><A NAME="_Ref352404524">Filter Role</A></H3>\r
-\r
-<P>\r
-The Filter role allows a FastCGI application to process\r
-a requested file before it is returned to the client. </FONT>\r
-<P>\r
-Let's assume that the Web server is configured so\r
-that all files with the .</FONT><TT><FONT FACE="Courier">sgml\r
-</FONT></TT>extension are processed by a SGML-to-HTML\r
-FastCGI filter application, and the user accesses the following\r
-URL:</FONT>\r
-<P>\r
- </FONT><TT><FONT FACE="Courier">/document.sgml</FONT></TT>\r
-<P>\r
-After the Web server makes an access control decision\r
-and maps this URL to a content file, it invokes the FastCGI filter\r
-application with this file available as input. The FastCGI program's\r
-HTML output is sent back to the client, just as in the responder\r
-role. The process is outlined in Figure 3.</FONT>\r
-<P>\r
-<CENTER><IMG SRC="img00003.gif"><A NAME="_Ref352560526">Figure\r
-3</FONT></A></CENTER>\r
-<P>\r
-Filter applications can significantly improve performance\r
-by caching filter results (the server provides the modification\r
-time in the request information so that applications can flush\r
-the cache when the server file has been modified).</FONT>\r
-<P>\r
-The Filter role is useful for:</FONT>\r
-<UL>\r
-<LI>On-the-fly format conversions</FONT>\r
-<LI>Dynamic documents (such as documents with embedded\r
-SQL queries, or dynamic advertisement insertion)</FONT>\r
-<LI>Applying a standard template: headers, footers,\r
-and backgrounds</FONT>\r
-</UL>\r
-\r
-<H3>Authorizer Role</H3>\r
-\r
-<P>\r
-The Authorizer role allows a FastCGI application\r
-to make an access control decision for a request. The FastCGI\r
-application is invoked with all of the request information, just\r
-as in the Responder role. If the authorizer application generates\r
-a "200 OK" HTTP result, the Web server assumes that\r
-access is allowed and proceeds with the request. (The Web server\r
-may process other access checks, including other FastCGI authorizers,\r
-before access is ultimately allowed.) If the application generates\r
-any other response, that response is returned to the client and\r
-the request is ended. The response can be any valid HTTP response,\r
-including "Access Denied" or "Redirect".</FONT>\r
-<P>\r
-The Authorizer role is useful for:</FONT>\r
-<UL>\r
-<LI>Access control based on username and password,\r
-where the user information is looked up in an external database.</FONT>\r
-<LI>Complex access policies, such as time-of-day\r
-based access.</FONT>\r
-<LI>Smart-card challenge/response authentication.</FONT>\r
-<LI>Dynamic redirects, where the user is sent to\r
-different pages based on the request profile. </FONT>\r
-</UL>\r
-\r
-<H2><A NAME="_Ref352251764">4. FastCGI Application Library</A></H2>\r
-\r
-<P>\r
-Open Market has developed a FastCGI application library\r
-that implements the FastCGI protocol (hiding the protocol details\r
-from the developer). This library makes implementing FastCGI programs\r
-as easy as writing CGI applications.</FONT>\r
-<P>\r
-The application library provides a replacement for\r
-the C language standard I/O (stdio) routines, such as </FONT><TT><FONT FACE="Courier">printf()</FONT></TT>\r
-and </FONT><TT><FONT FACE="Courier">gets()</FONT></TT>.\r
- The library converts references to standard input, standard output,\r
-and standard error to the FastCGI protocol. References to other\r
-files "fall through" to the underlying operating system\r
-standard I/O routines.</FONT>\r
-<P>\r
-This approach has several benefits:</FONT>\r
-<UL>\r
-<LI>Developers don't have to learn a new API to develop\r
-FastCGI applications.</FONT>\r
-<LI>Existing CGI programs can be migrated with minimal\r
-source changes (CGI migration is described in more detail in the\r
-following section).</FONT>\r
-<LI>FastCGI interpreters for Perl, Tcl, and other\r
-interpreted languages can be built without modifying the interpreter\r
-source code.</FONT>\r
-</UL>\r
-\r
-<P>\r
-Here's a simple FastCGI application:<P>
-<PRE>
- #include <fcgi_stdio.h>
+<!-- $Id: fastcgi.htm,v 1.2 2001/05/14 13:00:32 robs Exp $ -->
+
+<BODY>
+
+
+
+<P>
+
+Open Market, Inc.
+
+<P>
+
+<CENTER><FONT SIZE=4 COLOR=#FFFFFF FACE="Impact">Technical White
+
+Paper<BR>
+
+</FONT></CENTER>
+
+<H1>FastCGI:<BR>
+
+A High-Performance Web Server Interface</H1>
+
+
+
+<P>
+
+April 1996<!--Please send comments to:-->
+
+<HR>
+
+<!-- payne@openmarket.com-->
+
+<H2>1. Introduction</H2>
+
+
+
+<P>
+
+The surge in the use of the Web by business has created
+
+a tremendous need for server extension applications that create
+
+dynamic content. These are the applications that will allow businesses
+
+to deliver products, services, and messages whose shape and content
+
+are in part determined by the interaction with, and knowledge
+
+of, the customers to which they are delivered.
+
+<P>
+
+This important movement away from static Web content
+
+is pushing the limits and exposing the weaknesses of the environment
+
+in which these applications are currently bound: CGI (Common Gateway
+
+Interface). Most importantly it does not offer the performance
+
+these applications require. A new communication infrastructure
+
+is needed to connect Web servers with these new applications.
+
+This is what led Open Market to develop FastCGI.
+
+<P>
+
+FastCGI is a fast, open, and secure Web server interface
+
+that solves the performance problems inherent in CGI, without
+
+introducing the overhead and complexity of proprietary APIs (Application
+
+Programming Interfaces).
+
+<P>
+
+This paper assumes that the reader has basic familiarity
+
+with Web technology and developing Web applications.
+
+<H3>Common Gateway Interface</H3>
+
+
+
+<P>
+
+The de facto standard interface for Web server applications
+
+is CGI, which was first implemented in the NCSA server. CGI has
+
+many benefits:
+
+<UL>
+
+<LI><B>Simplicity. </B><FONT>It is
+
+easy to understand.</FONT>
+
+<LI><B>Language independence.</B>
+
+CGI applications can be written in nearly any language.
+
+<LI><B>Process isolation.</B>
+
+Since applications run in separate processes, buggy applications
+
+cannot crash the Web server or access the server's private internal
+
+state.
+
+<LI><B>Open standard.</B> Some
+
+form of CGI has been implemented on every Web server.
+
+<LI><B>Architecture independence.</B>
+
+CGI is not tied to any particular server architecture (single
+
+threaded, multi-threaded, etc.).
+
+</UL>
+
+
+
+<P>
+
+CGI also has some significant drawbacks. The leading
+
+problem is performance: Since a new process is created for each
+
+request and thrown away when the request is done, efficiency is
+
+poor.
+
+<P>
+
+CGI also has limited functionality: It only supports
+
+a simple "responder" role, where the application generates
+
+the response that is returned to the client. CGI programs can't
+
+link into other stages of Web server request processing, such
+
+as authorization and logging.
+
+<H3>Server APIs</H3>
+
+
+
+<P>
+
+In response to the performance problems for CGI,
+
+several vendors have developed APIs for their servers. The two
+
+most notable are NSAPI from Netscape and ISAPI from Microsoft.
+
+ The freely available Apache server also has an API.
+
+<P>
+
+Applications linked into the server API may be significantly
+
+faster than CGI programs. The CGI startup/initialization problem
+
+is improved, because the application runs in the server process
+
+and is persistent across requests. Web server APIs also offer
+
+more functionality than CGI: you can write extensions that perform
+
+access control, get access to the server's log file, and link
+
+in to other stages in the server's request processing.
+
+<P>
+
+However, APIs sacrifice all of CGI's benefits. Vendor
+
+APIs have the following problems:
+
+<UL>
+
+<LI><B>Complexity.</B> Vendor
+
+APIs introduce a steep learning curve, with increased implementation
+
+and maintenance costs.
+
+<LI><B>Language dependence.</B>
+
+ Applications have to be written in a language supported by the
+
+vendor API (usually C/C++). Perl, the most popular language for
+
+CGI programs, can't be used with any existing vendor API.
+
+<LI><B>No process isolation. </B><FONT>Since
+
+the applications run in the server's address space, buggy applications
+
+can corrupt the core server (or each other). A malicious or buggy
+
+application can compromise server security, and bugs in the core
+
+server can corrupt applications.</FONT>
+
+<LI><B>Proprietary.</B> Coding
+
+your application to a particular API locks you into a particular
+
+vendor's server.
+
+<LI><B>Tie-in to server architecture.</B>
+
+ API applications have to share the same architecture as the server:
+
+ If the Web server is multi-threaded, the application has to be
+
+thread-safe. If the Web server has single-threaded processes,
+
+multi-threaded applications don't gain any performance advantage.
+
+ Also, when the vendor changes the server's architecture, the
+
+API will usually have to change, and applications will have to
+
+be adapted or rewritten.
+
+</UL>
+
+
+
+<H3>FastCGI</H3>
+
+
+
+<P>
+
+The FastCGI interface combines the best aspects of
+
+CGI and vendor APIs. Like CGI, FastCGI applications run in separate,
+
+isolated processes. FastCGI's advantages include:
+
+<UL>
+
+<LI><B>Performance.</B> FastCGI
+
+processes are persistent-they are reused to handle multiple requests.
+
+ This solves the CGI performance problem of creating new processes
+
+for each request.
+
+<LI><B>Simplicity, with easy migration from CGI.</B>
+
+ The FastCGI application library (described on page 9) simplifies
+
+the migration of existing CGI applications. Applications built
+
+with the application library can also run as CGI programs, for
+
+backward compatibility with old Web servers.
+
+<LI><B>Language independence.</B>
+
+Like CGI, FastCGI applications can be written in any language,
+
+not just languages supported by the vendor API.
+
+<LI><B>Process isolation.</B>
+
+A buggy FastCGI application cannot crash or corrupt the core server
+
+or other applications. A malicious FastCGI application cannot
+
+steal any secrets (such as session keys for encryption) from the
+
+Web server.
+
+<LI><B>Non-proprietary.</B>
+
+FastCGI is supported in all of Open Market's server products,
+
+and support is under development for other Web servers, including
+
+the freely available Apache and NCSA servers, as well as commercial
+
+servers from Microsoft and Netscape.
+
+<LI><B>Architecture independence.</B>
+
+ The FastCGI interface is not tied to a particular server architecture.
+
+ Any Web server can implement the FastCGI interface. Also, FastCGI
+
+does not impose any architecture on the application: applications
+
+can be single or multi-threaded, regardless of the threading architecture
+
+of the Web server.
+
+<LI><B>Support for distributed computing.</B>
+
+ FastCGI provides the ability to run applications remotely, which
+
+is useful for distributing load and managing external Web sites.
+
+</UL>
+
+
+
+<P>
+
+The following sections describe the FastCGI interface,
+
+protocol, application library, and support in Open Market's WebServer
+
+products.
+
+<H2>2. FastCGI Interface</H2>
+
+
+
+<P>
+
+The functionality provided by the FastCGI interface
+
+is very similar to that provided by CGI. To best understand the
+
+FastCGI protocol, we review the CGI interface here. Basic CGI
+
+request processing proceeds as follows:
+
+<OL>
+
+<LI>For each request, the server creates a new process
+
+and the process initializes itself.
+
+<LI>The Web server passes the request information
+
+(such as remote host, username, HTTP headers, etc.) to the CGI
+
+program in environment variables.
+
+<LI>The Web server sends any client input (such as
+
+user-entered field values from an HTML form) to the CGI program's
+
+standard input.
+
+<LI>The CGI program writes any output to be returned
+
+to the client on standard output. Error information written to
+
+standard error is logged by the Web server.
+
+<LI>When the CGI process exits, the request is complete.
+
+</OL>
+
+
+
+<P>
+
+FastCGI is conceptually very similar to CGI, with
+
+two major differences:
+
+<UL>
+
+<LI>FastCGI processes are persistent: after finishing
+
+a request, they wait for a new request instead of exiting.
+
+<LI>Instead of using operating system environment
+
+variables and pipes, the FastCGI protocol multiplexes the environment
+
+information, standard input, output and error over a single full-duplex
+
+connection. This allows FastCGI programs to run on remote machines,
+
+using TCP connections between the Web server and the FastCGI application.
+
+</UL>
+
+
+
+<P>
+
+Request processing in a single-threaded FastCGI application
+
+proceeds as follows:
+
+<OL>
+
+<LI>The Web server creates FastCGI application processes
+
+to handle requests. The processes may be created at startup,
+
+or created on demand.
+
+<LI>The FastCGI program initializes itself, and waits
+
+for a new connection from the Web server.
+
+<LI>When a client request comes in, the Web server
+
+opens a connection to the FastCGI process. The server sends the
+
+CGI environment variable information and standard input over the
+
+connection.
+
+<LI>The FastCGI process sends the standard output
+
+and error information back to the server over the same connection.
+
+<LI>When the FastCGI process closes the connection,
+
+the request is complete. The FastCGI process then waits for another
+
+connection from the Web server.
+
+</OL>
+
+
+
+<P>
+
+FastCGI applications can run locally (on the same
+
+machine as the Web server) or remotely. For local applications,
+
+the server uses a full-duplex pipe to connect to the FastCGI application
+
+process. For remote applications, the server uses a TCP connection.
+
+<P>
+
+FastCGI applications can be single-threaded or multi-threaded.
+
+ For single threaded applications, the Web server maintains a
+
+pool of processes (if the application is running locally) to
+
+handle client requests. The size of the pool is user configurable.
+
+ Multi-threaded FastCGI applications may accept multiple connections
+
+from the Web server and handle them simultaneously in a single
+
+process. (For example, Java's built-in multi-threading, garbage
+
+collection, synchronization primitives, and platform independence
+
+make it a natural implementation language for multi-threaded FastCGI
+
+applications.)
+
+<H3>Remote FastCGI</H3>
+
+
+
+<P>
+
+FastCGI's ability to run applications remotely (over
+
+a TCP connection) provides some major benefits. These benefits
+
+are described in this section, along with some of the security
+
+issues that affect remote FastCGI applications.
+
+<H4>FastCGI with Firewalls</H4>
+
+
+
+<P>
+
+Applications that run on organizational (external) Web servers
+
+and depend on internal databases can be a challenge to administer.
+
+Figure 1 shows a typical organization, with an external Web server,
+
+a firewall restricting access to the internal network, and internal
+
+databases and applications.
+
+<P>
+
+<CENTER><IMG SRC="img00001.gif"><A NAME="_Ref352505891">Figure
+
+1</A></CENTER>
+
+<P>
+
+With CGI and vendor APIs, the application has to run on the Web
+
+server machine. This means the server administrator has to replicate
+
+the necessary database information onto the system hosting the
+
+Web server (which may be difficult to do in an automated way without
+
+compromising firewall security). Or, the administrator may build
+
+a "bridge" that allows access through the Web server
+
+to internal databases and applications (which is effectively re-inventing
+
+remote FastCGI).
+
+<P>
+
+With remote FastCGI, the applications can run on the internal
+
+network, simplifying the administrator's job. When used with
+
+appropriate firewall configuration and auditing, this approach
+
+provides a secure, high-performance, scalable way to bring internal
+
+applications and data to the external network.
+
+<H4>Load Distribution</H4>
+
+
+
+<P>
+
+For resource-intensive CGI and API applications, the Web server
+
+machine quickly becomes the bottleneck for overall throughput.
+
+The usual way to solve this performance problem is to buy a bigger,
+
+faster Web server machine, or to partition the Web site across
+
+several Web servers.
+
+<P>
+
+With remote FastCGI, the resource-intensive applications can be
+
+moved off the Web server machine, giving the server administrator
+
+additional flexibility in configuring the Web server. The administrator
+
+can configure FastCGI applications "behind the scenes"
+
+without having to change any content links or the external view
+
+of the Web site. The administrator can use several smaller, inexpensive
+
+server machines for applications, and can tailor each machine
+
+to the application it is hosting.
+
+<H4>Security Issues with Remote FastCGI</H4>
+
+
+
+<P>
+
+The two security issues with remote FastCGI connections are authentication
+
+and privacy. FastCGI applications should only accept connections
+
+from Web servers that they trust (the application library includes
+
+support for IP address validation). Future versions of the protocol
+
+will include support for applications authenticating Web servers,
+
+as well as support for running remote connections over secure
+
+transport protocols such as SSL or PCT.<!--This pargraph needs to be made stronger, going into the issues in a little more detail.-->
+
+
+
+<H3>The FastCGI Protocol</H3>
+
+
+
+<P>
+
+This section offers a brief introduction to the protocol
+
+used on the connection between the Web server and FastCGI application.
+
+ Most application developers will use the FastCGI application
+
+library and won't have to worry about the protocol details. However,
+
+specialized applications are free to implement the FastCGI protocol
+
+directly.
+
+<P>
+
+FastCGI uses a simple packet record format on the
+
+connection between the application and the Web server. The same
+
+record format is used in both directions and is outlined in Figure 2.
+
+<P>
+
+<CENTER><IMG SRC="img00002.gif"><A NAME="_Ref352404075">Figure
+
+2</A></CENTER>
+
+<P>
+
+The protocol version field specifies the version
+
+of the FastCGI protocol that is in use. The type field specifies
+
+the type of the record (described in the following section).
+
+The request ID identifies this record to a particular request,
+
+allowing multiple requests to be multiplexed over a single connection.
+
+ The data length field specifies the number of data bytes that
+
+follow.
+
+<P>
+
+The different FastCGI packet types are:
+
+<TABLE>
+
+
+
+<TR><TD WIDTH=186><TT><FONT FACE="Courier">FCGI_PARAMS</FONT></TT>
+
+</TD><TD WIDTH=228>Used for sending name/value pairs (CGI environment variables) from the Web server to the application.
+
+</TD></TR>
+
+
+
+<TR><TD WIDTH=186><TT><FONT FACE="Courier">FCGI_STDIN</FONT></TT>
+
+</TD><TD WIDTH=228>Used for sending the standard input from the Web server to the application.
+
+</TD></TR>
+
+
+
+<TR><TD WIDTH=186><TT><FONT FACE="Courier">FCGI_DATA</FONT></TT>
+
+</TD><TD WIDTH=228>Used for sending filter data to the application (for more information, see the filter role described on page 7.)
+
+</TD></TR>
+
+
+
+<TR><TD WIDTH=186><TT><FONT FACE="Courier">FCGI_STDOUT</FONT></TT>
+
+</TD><TD WIDTH=228>Used to send standard output from the application to the Web server.
+
+</TD></TR>
+
+
+
+<TR><TD WIDTH=186><TT><FONT FACE="Courier">FCGI_STDERR</FONT></TT>
+
+</TD><TD WIDTH=228>Used to send standard error information from the application to the Web server.
+
+</TD></TR>
+
+
+
+<TR><TD WIDTH=186><TT><FONT FACE="Courier">FCGI_END_REQUEST</FONT></TT>
+
+</TD><TD WIDTH=228>Ends the request (can be sent by either the server or the application).
+
+</TD></TR>
+
+
+
+</TABLE>
+
+
+
+<P>
+
+
+
+<P>
+
+For complete protocol details, see the <I>FastCGI Protocol Specification</I>,
+
+available from the Web site listed at the end of this paper.
+
+<H2>3. Application Roles</H2>
+
+
+
+<P>
+
+A major problem with CGI is its limited functionality:
+
+ CGI programs can only provide simple responses to requests.
+
+FastCGI provides expanded functionality with support for three
+
+different application "roles":
+
+<UL>
+
+<LI><B>Responder.</B> This is
+
+the basic FastCGI role, and corresponds to the simple functionality
+
+offered by CGI today.
+
+<LI><B>Filter.</B> The FastCGI
+
+application filters the requested Web server file before sending
+
+it to the client.
+
+<LI><B>Authorizer.</B> The FastCGI
+
+program performs an access control decision for the request (such
+
+as performing a username/password database lookup).
+
+</UL>
+
+
+
+<P>
+
+Other roles will be defined in the future. For instance,
+
+a "logger" role would be useful, where the FastCGI program
+
+would receive the server's log entries for real-time processing
+
+and analysis.
+
+<P>
+
+The roles are described in more detail in the following
+
+sections.
+
+<H3>Responder Role</H3>
+
+
+
+<P>
+
+FastCGI's Responder role is identical to the functionality
+
+provided by CGI today. When a request comes into the server,
+
+the FastCGI program generates the response that's returned to
+
+the client (typically an HTML page).
+
+<H3><A NAME="_Ref352404524">Filter Role</A></H3>
+
+
+
+<P>
+
+The Filter role allows a FastCGI application to process
+
+a requested file before it is returned to the client.
+
+<P>
+
+Let's assume that the Web server is configured so
+
+that all files with the .<TT><FONT FACE="Courier">sgml
+
+</FONT></TT>extension are processed by a SGML-to-HTML
+
+FastCGI filter application, and the user accesses the following
+
+URL:
+
+<P>
+
+ <TT><FONT FACE="Courier">/document.sgml</FONT></TT>
+
+<P>
+
+After the Web server makes an access control decision
+
+and maps this URL to a content file, it invokes the FastCGI filter
+
+application with this file available as input. The FastCGI program's
+
+HTML output is sent back to the client, just as in the responder
+
+role. The process is outlined in Figure 3.
+
+<P>
+
+<CENTER><IMG SRC="img00003.gif"><A NAME="_Ref352560526">Figure
+
+3</A></CENTER>
+
+<P>
+
+Filter applications can significantly improve performance
+
+by caching filter results (the server provides the modification
+
+time in the request information so that applications can flush
+
+the cache when the server file has been modified).
+
+<P>
+
+The Filter role is useful for:
+
+<UL>
+
+<LI>On-the-fly format conversions
+
+<LI>Dynamic documents (such as documents with embedded
+
+SQL queries, or dynamic advertisement insertion)
+
+<LI>Applying a standard template: headers, footers,
+
+and backgrounds
+
+</UL>
+
+
+
+<H3>Authorizer Role</H3>
+
+
+
+<P>
+
+The Authorizer role allows a FastCGI application
+
+to make an access control decision for a request. The FastCGI
+
+application is invoked with all of the request information, just
+
+as in the Responder role. If the authorizer application generates
+
+a "200 OK" HTTP result, the Web server assumes that
+
+access is allowed and proceeds with the request. (The Web server
+
+may process other access checks, including other FastCGI authorizers,
+
+before access is ultimately allowed.) If the application generates
+
+any other response, that response is returned to the client and
+
+the request is ended. The response can be any valid HTTP response,
+
+including "Access Denied" or "Redirect".
+
+<P>
+
+The Authorizer role is useful for:
+
+<UL>
+
+<LI>Access control based on username and password,
+
+where the user information is looked up in an external database.
+
+<LI>Complex access policies, such as time-of-day
+
+based access.
+
+<LI>Smart-card challenge/response authentication.
+
+<LI>Dynamic redirects, where the user is sent to
+
+different pages based on the request profile.
+
+</UL>
+
+
+
+<H2><A NAME="_Ref352251764">4. FastCGI Application Library</A></H2>
+
+
+
+<P>
+
+Open Market has developed a FastCGI application library
+
+that implements the FastCGI protocol (hiding the protocol details
+
+from the developer). This library makes implementing FastCGI programs
+
+as easy as writing CGI applications.
+
+<P>
+
+The application library provides a replacement for
+
+the C language standard I/O (stdio) routines, such as <TT><FONT FACE="Courier">printf()</FONT></TT>
+
+and <TT><FONT FACE="Courier">gets()</FONT></TT>.
+
+ The library converts references to standard input, standard output,
+
+and standard error to the FastCGI protocol. References to other
+
+files "fall through" to the underlying operating system
+
+standard I/O routines.
+
+<P>
+
+This approach has several benefits:
+
+<UL>
+
+<LI>Developers don't have to learn a new API to develop
+
+FastCGI applications.
+
+<LI>Existing CGI programs can be migrated with minimal
+
+source changes (CGI migration is described in more detail in the
+
+following section).
+
+<LI>FastCGI interpreters for Perl, Tcl, and other
+
+interpreted languages can be built without modifying the interpreter
+
+source code.
+
+</UL>
+
+
+
+<P>
+
+Here's a simple FastCGI application:<P>
+<PRE>
+ #include <fcgi_stdio.h>
+
+ void main(void)
+ {
+ int count = 0;
+ while(FCGI_Accept() >= 0) {
+ printf("Content-type: text/html\r\n");
+ printf("\r\n");
+ printf("Hello world!<br>\r\n");
+ printf("Request number %d.", count++);
+ }
+ exit(0);
+ }
+</PRE>
+This application returns a "Hello world"
+
+HTML response to the client. It also keeps a counter of the number
+
+of times it has been accessed, displaying the value of the counter
+
+at each request.
+
+<P>
+
+The <TT>fcgi_stdio.h</TT>
+
+header file provides the FastCGI replacement routines for the
+
+C standard I/O library. The <TT>FCGI_Accept()</TT>
+
+routine accepts a new request from the Web server.
+
+<H3>Migrating Existing CGI Programs</H3>
+
+
+
+<P>
+
+The application library was designed to make migration
+
+of existing CGI programs as simple as possible. Many applications
+
+can be converted by adding a loop around the main request processing
+
+code and recompiling with the FastCGI application library. FastCGI
+
+applications have the following structure, with an initialization
+
+section and a request processing loop:<p>
+
+
+<I>Initialize application;<BR>
+
+</I><TT>while(FCGI_Accept() >= 0) {</TT><BR>
+
+ <I>Process request</I>;<BR>
+
+<TT>}</TT>
+
+<P>
+
+To ease migration to FastCGI, executables built with
+
+the application library can run as either CGI or FastCGI programs,
+
+depending on how they are invoked. The library detects the execution
+
+environment and automatically selects FastCGI or regular I/O routines,
+
+as appropriate.
+
+<P>
+
+After migration, developers can clean up their FastCGI
+
+applications for best performance:
+
+<UL>
+
+<LI>Fix any resource leaks. Many CGI programs do
+
+not attempt to manage memory or close files, because they assume
+
+the world is going to be cleaned up when they exit. (If you don't
+
+want to clean up your program, you can just have your process
+
+assume that it is leaking memory and exit after processing some
+
+fixed number of requests.) Purify from Pure Software is one of
+
+a number of excellent tools for finding leaks and other memory
+
+use problems.
+
+<LI>Fix any problems with retained application state.
+
+ The application must ensure that any state that it creates in
+
+processing one request has no unintended effects on later requests.
+
+
+
+<LI>Collapse functionality. A common practice with
+
+CGI applications is to implement many small programs, with one
+
+function per program. CGI encourages this, because smaller programs
+
+load faster. With FastCGI, it's better to have related functionality
+
+in a single executable, so there are fewer processes to manage
+
+and applications can take advantage of sharing cached information
+
+across functions.
+
+</UL>
+
+
+
+<P>
+
+Applications written in Perl, Tcl, and other scripting
+
+languages can be migrated by using a language interpreter built
+
+with the application library. FastCGI-integrated Tcl and Perl
+
+interpreters for popular Unix platforms are available from Open
+
+Market. The interpreters are backward-compatible: They can run
+
+standard Tcl and Perl applications.
+
+<H2>5. FastCGI in the Open Market WebServer</H2>
+
+
+
+<P>
+
+This section describes the FastCGI support in the
+
+following Open Market server products:
+
+<UL>
+
+<LI>Open Market WebServer V2.0
+
+<LI>Open Market Secure WebServer V2.0
+
+<LI>Open Market Secure WebServer (Global) V2.0
+
+</UL>
+
+
+
+<P>
+
+For more information about FastCGI support, see
+
+the <I>Open Market WebServer Installation and Configuration Guide</I>.
+
+<H3>Server Configuration</H3>
+
+
+
+<P>
+
+FastCGI applications are configured with the server's
+
+configuration file. Configuration has two parts.
+
+<P>
+
+First, the server administrator defines an <I>application
+
+class</I>. For local applications, the application class specifies
+
+the details of running the FastCGI application, such as:
+
+<UL>
+
+<LI>The pathname of the application executable.
+
+<LI>Any arguments and environment variables to pass
+
+to the process at startup.
+
+<LI>The number of processes to run.
+
+</UL>
+
+
+
+<P>
+
+For remote applications, the class configuration
+
+information includes the host and TCP port to connect to. The
+
+Web server assumes that the FastCGI application has been started
+
+on the remote host. If a request comes in and the server can't
+
+connect to the FastCGI TCP port, the server logs an error and
+
+returns an error page to the client.
+
+<P>
+
+The second configuration step is mapping the application
+
+class to a role:
+
+<UL>
+
+<LI>For responder roles, the administrator configures
+
+some part of the URL space to be handled by the FastCGI application.
+
+ For example, all URLs beginning with <FONT FACE="Courier">/rollcall/</FONT>
+
+might be handled by the employee database application.
+
+<LI>For filter roles, the administrator configures
+
+a file extension to be handled by a filter application. For example,
+
+all files with the <FONT FACE="Courier">.sql</FONT>
+
+extension could be handled by a SQL query lookup filter.
+
+<LI>For authorizer roles, the administrator configures
+
+an authorizer application in the same manner as other access methods
+
+(hostname, username/password, etc.) A request must pass <I>all
+
+</I>access control checks (possibly including multiple FastCGI
+
+authorizers) before access is allowed.
+
+</UL>
+
+
+
+<H3>Basic FastCGI</H3>
+
+
+
+<P>
+
+To simplify migration for existing CGI programs,
+
+the WebServer provides a simple way to install new FastCGI programs
+
+without having to reconfigure the server. However, this approach
+
+doesn't offer all of the performance benefits of FastCGI application
+
+classes.
+
+<P>
+
+The WebServer treats any file with the extension
+
+<FONT FACE="Courier">.fcg</FONT> as
+
+a FastCGI application. When a request corresponds to such a file,
+
+the WebServer creates a new FastCGI process to handle the request,
+
+and shuts down the process when the request is complete (just
+
+as in CGI). In this mode of operation performance is comparable
+
+to CGI. Future versions of the WebServer will improve performance
+
+by automatically caching processes and re-using them for subsequent
+
+requests.
+
+<H3>Session Affinity</H3>
+
+
+
+<P>
+
+FastCGI programs can improve performance by caching
+
+information in the application process. For applications that
+
+require frequent but expensive operations such as validating a
+
+username/password in an external database for each request, this
+
+technique can significantly improve performance.
+
+<P>
+
+To improve the effectiveness of this technique, the
+
+WebServer implements <I>session affinity</I>. When session affinity
+
+is enabled, the WebServer arranges for all requests in a user
+
+session to be handled by the same FastCGI application process.
+
+ What constitutes a "session" is configurable. The
+
+default configuration uses the WebServer's built-in session tracking
+
+facility to identify user sessions. However, the server administrator
+
+can use any part of the request information for the session affinity
+
+mapping: the URL path, the client's hostname, the username, etc.<!--Talk about applications that need to hold onto resources for the user (such as open connections to the database).-->
+
+
+
+<H2>6. FastCGI Performance Analysis</H2>
+
+
+
+<P>
+
+How fast is FastCGI? The answer depends on the application.
+
+ This section contains some real FastCGI performance measurements,
+
+as well as guidelines for estimating the FastCGI speedup.
+
+<H3>FastCGI vs CGI</H3>
+
+
+
+<P>
+
+We measured the relative performance of CGI, FastCGI,
+
+and static files on the Open Market WebServer, using a simple
+
+application that generates a fixed number of output bytes. The
+
+following table shows the measured request processing time for
+
+different request types on a typical platform. The times are
+
+measured from the client perspective and include client, server,
+
+and application processing time.
+
+<TABLE BORDERCOLOR=#000000 BORDER=2>
+
+
+
+<TR><TD WIDTH=72><CENTER><FONT SIZE=2 FACE="Arial Narrow">Static file</FONT></CENTER>
+
+</TD><TD WIDTH=180><CENTER><FONT SIZE=2 FACE="Arial Narrow">21ms + 0.19ms per Kbyte</FONT></CENTER>
+
+</TD></TR>
+
+
+
+<TR><TD WIDTH=72><CENTER><FONT SIZE=2 FACE="Arial Narrow">FastCGI</FONT></CENTER>
+
+</TD><TD WIDTH=180><CENTER><FONT SIZE=2 FACE="Arial Narrow">22ms + 0.28ms per Kbyte</FONT></CENTER>
+
+</TD></TR>
+
+
+
+<TR><TD WIDTH=72><CENTER><FONT SIZE=2 FACE="Arial Narrow">CGI</FONT></CENTER>
+
+</TD><TD WIDTH=180><CENTER><FONT SIZE=2 FACE="Arial Narrow">59ms + 0.37ms per Kbyte</FONT></CENTER>
+
+</TD></TR>
+
+
+
+</TABLE>
+
+
+
+<P>
+
+FastCGI performance is comparable to serving static files, and
+
+significantly better than CGI (clearly showing the high overhead
+
+for process creation). Real applications have an additional time
+
+component: process initialization, which should be added to overall
+
+request processing time.
+
+<P>
+
+Let's use this data to estimate the speedup from migrating a typical
+
+database CGI application to FastCGI. Assume the application takes
+
+50ms to initialize the database connection and generates 5K of
+
+output data. Request performance can be computed as follows:
+
+<TABLE>
+
+
+
+<TR><TD WIDTH=108>CGI </TD><TD WIDTH=331>59ms + 50ms + (0.37ms)(5) = 111ms
+
+</TD></TR>
+
+
+
+<TR><TD WIDTH=108>FastCGI</TD><TD WIDTH=331>22ms + (0.28ms)(5) = 23ms
+
+</TD></TR>
+
+
+
+</TABLE>
+
+
+
+<P>
+
+In this example, FastCGI has a 5x performance advantage over CGI,
+
+mostly due to savings from not having to create and initialize
+
+new processes for each request.<!--Need to talk about FastCGI vs proprietary APIs.-->
+
+
+
+<H2>7. Conclusions</H2>
+
+
+
+<P>
+
+Today's Web business applications need a platform
+
+that's fast, open, maintainable, straightforward, stable, and
+
+secure. FastCGI's design meets these requirements, and provides
+
+for a logical extension from proven and widely deployed CGI technology.
+
+ This allows developers to take advantage of FastCGI's benefits
+
+without losing their existing investment in CGI applications.<!--Need to talk about NT.-->
+
+<!--Need to give "more punch" 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. -->
+
+<H2>8. For More Information</H2>
+
+
+
+<P>
+
+For more information about Open Market and our products,
+
+visit our Web site at:<FONT FACE="Courier">http://www.openmarket.com/</FONT>
+
+<P>
+
+For more information about the FastCGI protocol and
+
+the developer's kit, and the latest information about FastCGI
+
+standardization and support in other Web servers, visit the FastCGI
+
+project page at:<FONT FACE="Courier">http://www.openmarket.com/fastcgi/</FONT>
+
+</BODY>
+
+
+
+</HTML>
- void main(void)
- {
- int count = 0;
- while(FCGI_Accept() >= 0) {
- printf("Content-type: text/html\r\n");
- printf("\r\n");
- printf("Hello world!<br>\r\n");
- printf("Request number %d.", count++);
- }
- exit(0);
- }
-</PRE>
-This application returns a "Hello world"\r
-HTML response to the client. It also keeps a counter of the number\r
-of times it has been accessed, displaying the value of the counter\r
-at each request.</FONT>\r
-<P>\r
-The <TT>fcgi_stdio.h</TT>\r
-header file provides the FastCGI replacement routines for the\r
-C standard I/O library. The <TT>FCGI_Accept()</TT>\r
-routine accepts a new request from the Web server.</FONT>\r
-<H3>Migrating Existing CGI Programs</H3>\r
-\r
-<P>\r
-The application library was designed to make migration\r
-of existing CGI programs as simple as possible. Many applications\r
-can be converted by adding a loop around the main request processing\r
-code and recompiling with the FastCGI application library. FastCGI\r
-applications have the following structure, with an initialization\r
-section and a request processing loop:<p>
-\r
-<I>Initialize application;<BR>\r
-</I><TT>while(FCGI_Accept() >= 0) {</TT><BR>\r
- <I>Process request</I>;<BR>\r
-<TT>}</TT>\r
-<P>\r
-To ease migration to FastCGI, executables built with\r
-the application library can run as either CGI or FastCGI programs,\r
-depending on how they are invoked. The library detects the execution\r
-environment and automatically selects FastCGI or regular I/O routines,\r
-as appropriate.</FONT>\r
-<P>\r
-After migration, developers can clean up their FastCGI\r
-applications for best performance:</FONT>\r
-<UL>\r
-<LI>Fix any resource leaks. Many CGI programs do\r
-not attempt to manage memory or close files, because they assume\r
-the world is going to be cleaned up when they exit. (If you don't\r
-want to clean up your program, you can just have your process\r
-assume that it is leaking memory and exit after processing some\r
-fixed number of requests.) Purify from Pure Software is one of\r
-a number of excellent tools for finding leaks and other memory\r
-use problems.</FONT>\r
-<LI>Fix any problems with retained application state.\r
- The application must ensure that any state that it creates in\r
-processing one request has no unintended effects on later requests.\r
- </FONT>\r
-<LI>Collapse functionality. A common practice with\r
-CGI applications is to implement many small programs, with one\r
-function per program. CGI encourages this, because smaller programs\r
-load faster. With FastCGI, it's better to have related functionality\r
-in a single executable, so there are fewer processes to manage\r
-and applications can take advantage of sharing cached information\r
-across functions.</FONT>\r
-</UL>\r
-\r
-<P>\r
-Applications written in Perl, Tcl, and other scripting\r
-languages can be migrated by using a language interpreter built\r
-with the application library. FastCGI-integrated Tcl and Perl\r
-interpreters for popular Unix platforms are available from Open\r
-Market. The interpreters are backward-compatible: They can run\r
-standard Tcl and Perl applications. </FONT>\r
-<H2>5. FastCGI in the Open Market WebServer</H2>\r
-\r
-<P>\r
-This section describes the FastCGI support in the\r
-following Open Market server products:</FONT>\r
-<UL>\r
-<LI>Open Market WebServer V2.0</FONT>\r
-<LI>Open Market Secure WebServer V2.0</FONT>\r
-<LI>Open Market Secure WebServer (Global) V2.0</FONT>\r
-</UL>\r
-\r
-<P>\r
-For more information about FastCGI support, see\r
-the <I>Open Market WebServer Installation and Configuration Guide</I>.</FONT>\r
-<H3>Server Configuration</H3>\r
-\r
-<P>\r
-FastCGI applications are configured with the server's\r
-configuration file. Configuration has two parts.</FONT>\r
-<P>\r
-First, the server administrator defines an <I>application\r
-class</I>. For local applications, the application class specifies\r
-the details of running the FastCGI application, such as:</FONT>\r
-<UL>\r
-<LI>The pathname of the application executable.</FONT>\r
-<LI>Any arguments and environment variables to pass\r
-to the process at startup.</FONT>\r
-<LI>The number of processes to run.</FONT>\r
-</UL>\r
-\r
-<P>\r
-For remote applications, the class configuration\r
-information includes the host and TCP port to connect to. The\r
-Web server assumes that the FastCGI application has been started\r
-on the remote host. If a request comes in and the server can't\r
-connect to the FastCGI TCP port, the server logs an error and\r
-returns an error page to the client.</FONT>\r
-<P>\r
-The second configuration step is mapping the application\r
-class to a role:</FONT>\r
-<UL>\r
-<LI>For responder roles, the administrator configures\r
-some part of the URL space to be handled by the FastCGI application.\r
- For example, all URLs beginning with </FONT><FONT FACE="Courier">/rollcall/</FONT>\r
-might be handled by the employee database application.</FONT>\r
-<LI>For filter roles, the administrator configures\r
-a file extension to be handled by a filter application. For example,\r
-all files with the </FONT><FONT FACE="Courier">.sql</FONT>\r
-extension could be handled by a SQL query lookup filter. </FONT>\r
-<LI>For authorizer roles, the administrator configures\r
-an authorizer application in the same manner as other access methods\r
-(hostname, username/password, etc.) A request must pass <I>all\r
-</I>access control checks (possibly including multiple FastCGI\r
-authorizers) before access is allowed. </FONT>\r
-</UL>\r
-\r
-<H3>Basic FastCGI</H3>\r
-\r
-<P>\r
-To simplify migration for existing CGI programs,\r
-the WebServer provides a simple way to install new FastCGI programs\r
-without having to reconfigure the server. However, this approach\r
-doesn't offer all of the performance benefits of FastCGI application\r
-classes.</FONT>\r
-<P>\r
-The WebServer treats any file with the extension\r
-</FONT><FONT FACE="Courier">.fcg</FONT> as\r
-a FastCGI application. When a request corresponds to such a file,\r
-the WebServer creates a new FastCGI process to handle the request,\r
-and shuts down the process when the request is complete (just\r
-as in CGI). In this mode of operation performance is comparable\r
-to CGI. Future versions of the WebServer will improve performance\r
-by automatically caching processes and re-using them for subsequent\r
-requests.</FONT>\r
-<H3>Session Affinity</H3>\r
-\r
-<P>\r
-FastCGI programs can improve performance by caching\r
-information in the application process. For applications that\r
-require frequent but expensive operations such as validating a\r
-username/password in an external database for each request, this\r
-technique can significantly improve performance.</FONT>\r
-<P>\r
-To improve the effectiveness of this technique, the\r
-WebServer implements <I>session affinity</I>. When session affinity\r
-is enabled, the WebServer arranges for all requests in a user\r
-session to be handled by the same FastCGI application process.\r
- What constitutes a "session" is configurable. The\r
-default configuration uses the WebServer's built-in session tracking\r
-facility to identify user sessions. However, the server administrator\r
-can use any part of the request information for the session affinity\r
-mapping: the URL path, the client's hostname, the username, etc.<!--Talk about applications that need to hold onto resources for the user (such as open connections to the database).--></FONT>\r
-\r
-<H2>6. FastCGI Performance Analysis</H2>\r
-\r
-<P>\r
-How fast is FastCGI? The answer depends on the application.\r
- This section contains some real FastCGI performance measurements,\r
-as well as guidelines for estimating the FastCGI speedup. </FONT>\r
-<H3>FastCGI vs CGI</H3>\r
-\r
-<P>\r
-We measured the relative performance of CGI, FastCGI,\r
-and static files on the Open Market WebServer, using a simple\r
-application that generates a fixed number of output bytes. The\r
-following table shows the measured request processing time for\r
-different request types on a typical platform. The times are\r
-measured from the client perspective and include client, server,\r
-and application processing time.</FONT>\r
-<TABLE BORDERCOLOR=#000000 BORDER=2>\r
-\r
-<TR><TD WIDTH=72><CENTER><FONT SIZE=2 FACE="Arial Narrow">Static file</FONT></CENTER>\r
-</TD><TD WIDTH=180><CENTER><FONT SIZE=2 FACE="Arial Narrow">21ms + 0.19ms per Kbyte</FONT></CENTER>\r
-</TD></TR>\r
-\r
-<TR><TD WIDTH=72><CENTER><FONT SIZE=2 FACE="Arial Narrow">FastCGI</FONT></CENTER>\r
-</TD><TD WIDTH=180><CENTER><FONT SIZE=2 FACE="Arial Narrow">22ms + 0.28ms per Kbyte</FONT></CENTER>\r
-</TD></TR>\r
-\r
-<TR><TD WIDTH=72><CENTER><FONT SIZE=2 FACE="Arial Narrow">CGI</FONT></CENTER>\r
-</TD><TD WIDTH=180><CENTER><FONT SIZE=2 FACE="Arial Narrow">59ms + 0.37ms per Kbyte</FONT></CENTER>\r
-</TD></TR>\r
-\r
-</TABLE>\r
-\r
-<P>\r
-FastCGI performance is comparable to serving static files, and\r
-significantly better than CGI (clearly showing the high overhead\r
-for process creation). Real applications have an additional time\r
-component: process initialization, which should be added to overall\r
-request processing time.\r
-<P>\r
-Let's use this data to estimate the speedup from migrating a typical\r
-database CGI application to FastCGI. Assume the application takes\r
-50ms to initialize the database connection and generates 5K of\r
-output data. Request performance can be computed as follows:\r
-<TABLE>\r
-\r
-<TR><TD WIDTH=108>CGI </TD><TD WIDTH=331>59ms + 50ms + (0.37ms)(5) = 111ms\r
-</TD></TR>\r
-\r
-<TR><TD WIDTH=108>FastCGI</TD><TD WIDTH=331>22ms + (0.28ms)(5) = 23ms\r
-</TD></TR>\r
-\r
-</TABLE>\r
-\r
-<P>\r
-In this example, FastCGI has a 5x performance advantage over CGI,\r
-mostly due to savings from not having to create and initialize\r
-new processes for each request.<!--Need to talk about FastCGI vs proprietary APIs.-->\r
-\r
-<H2>7. Conclusions</H2>\r
-\r
-<P>\r
-Today's Web business applications need a platform\r
-that's fast, open, maintainable, straightforward, stable, and\r
-secure. FastCGI's design meets these requirements, and provides\r
-for a logical extension from proven and widely deployed CGI technology.\r
- This allows developers to take advantage of FastCGI's benefits\r
-without losing their existing investment in CGI applications.<!--Need to talk about NT.--></FONT>\r
-<!--Need to give "more punch" 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. -->\r
-<H2>8. For More Information</H2>\r
-\r
-<P>\r
-For more information about Open Market and our products,\r
-visit our Web site at:</FONT><FONT FACE="Courier">http://www.openmarket.com/</FONT>\r
-<P>\r
-For more information about the FastCGI protocol and\r
-the developer's kit, and the latest information about FastCGI\r
-standardization and support in other Web servers, visit the FastCGI\r
-project page at:</FONT><FONT FACE="Courier">http://www.openmarket.com/fastcgi/</FONT>\r
-</BODY>\r
-\r
-</HTML>\r
projects / catagits/fcgi2.git / commitdiff