-<HTML>\r
-\r
-<HEAD>\r
-\r
-<TITLE>FastCGI</TITLE>\r
-\r
-<META NAME="GENERATOR" CONTENT="Internet Assistant for Microsoft Word 2.0z">\r
-</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>
+<HTML>
+ <HEAD>
+ <TITLE>
+ FastCGI
+ </TITLE>
+ <META NAME="GENERATOR" CONTENT="Internet Assistant for Microsoft Word 2.0z">
+<STYLE TYPE="text/css">
+ div.c5 {font-family: Arial Narrow; font-size: 80%; text-align: center}
+ span.c4 {font-family: Courier}
+ tt.c3 {font-family: Courier}
+ div.c2 {text-align: center}
+ div.c1 {color: #FFFFFF; font-family: Impact; font-size: 120%; text-align: center}
+</STYLE>
+ </HEAD>
+ <!--Copyright (c) 1996 Open Market, Inc. -->
+ <!--See the file "LICENSE" for information on usage and redistribution-->
+ <!--of this file, and for a DISCLAIMER OF ALL WARRANTIES. -->
+ <!-- $Id: fastcgi.htm,v 1.4 2002/02/25 00:45:06 robs Exp $ -->
+ <BODY>
+ <P>
+ Open Market, Inc.
+ </P>
+ <P>
+ </P>
+ <DIV CLASS="c1">
+ Technical White Paper<BR>
+ </DIV>
+ <H1>
+ FastCGI:<BR>
+ A High-Performance Web Server Interface
+ </H1>
+ <P>
+ April 1996<!--Please send comments to:-->
+ </P>
+ <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>
+ <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>
+ <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>
+ <P>
+ This paper assumes that the reader has basic familiarity with Web technology and developing Web applications.
+ </P>
+ <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:
+ </P>
+ <UL>
+ <LI>
+ <B>Simplicity.</B> <SPAN>It is easy to understand.</SPAN>
+ </LI>
+ <LI>
+ <B>Language independence.</B> CGI applications can be written in nearly any language.
+ </LI>
+ <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>
+ <LI>
+ <B>Open standard.</B> Some form of CGI has been implemented on every Web server.
+ </LI>
+ <LI>
+ <B>Architecture independence.</B> CGI is not tied to any particular server architecture (single threaded,
+ multi-threaded, etc.).
+ </LI>
+ </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>
+ <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.
+ </P>
+ <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>
+ <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>
+ <P>
+ However, APIs sacrifice all of CGI's benefits. Vendor APIs have the following problems:
+ </P>
+ <UL>
+ <LI>
+ <B>Complexity.</B> Vendor APIs introduce a steep learning curve, with increased implementation and
+ maintenance costs.
+ </LI>
+ <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>
+ <LI>
+ <B>No process isolation.</B> <SPAN>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.</SPAN>
+ </LI>
+ <LI>
+ <B>Proprietary.</B> Coding your application to a particular API locks you into a particular vendor's
+ server.
+ </LI>
+ <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.
+ </LI>
+ </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:
+ </P>
+ <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>
+ <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>
+ <LI>
+ <B>Language independence.</B> Like CGI, FastCGI applications can be written in any language, not just
+ languages supported by the vendor API.
+ </LI>
+ <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>
+ <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>
+ <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>
+ <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.
+ </LI>
+ </UL>
+ <P>
+ The following sections describe the FastCGI interface, protocol, application library, and support in Open
+ Market's WebServer products.
+ </P>
+ <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:
+ </P>
+ <OL>
+ <LI>
+ For each request, the server creates a new process and the process initializes itself.
+ </LI>
+ <LI>
+ The Web server passes the request information (such as remote host, username, HTTP headers, etc.) to the
+ CGI program in environment variables.
+ </LI>
+ <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>
+ <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>
+ <LI>
+ When the CGI process exits, the request is complete.
+ </LI>
+ </OL>
+ <P>
+ FastCGI is conceptually very similar to CGI, with two major differences:
+ </P>
+ <UL>
+ <LI>
+ FastCGI processes are persistent: after finishing a request, they wait for a new request instead of
+ exiting.
+ </LI>
+ <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.
+ </LI>
+ </UL>
+ <P>
+ Request processing in a single-threaded FastCGI application proceeds as follows:
+ </P>
+ <OL>
+ <LI>
+ The Web server creates FastCGI application processes to handle requests. The processes may be created at
+ startup, or created on demand.
+ </LI>
+ <LI>
+ The FastCGI program initializes itself, and waits for a new connection from the Web server.
+ </LI>
+ <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>
+ <LI>
+ The FastCGI process sends the standard output and error information back to the server over the same
+ connection.
+ </LI>
+ <LI>
+ When the FastCGI process closes the connection, the request is complete. The FastCGI process then waits for
+ another connection from the Web server.
+ </LI>
+ </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>
+ <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.)
+ </P>
+ <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.
+ </P>
+ <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>
+ <P>
+ </P>
+ <DIV CLASS="c2">
+ <IMG ALT="error-file:TidyOut.log" SRC="img00001.gif"><A NAME="_Ref352505891">Figure 1</A>
+ </DIV>
+ <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>
+ <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.
+ </P>
+ <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>
+ <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.
+ </P>
+ <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.-->
+ </P>
+ <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>
+ <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>
+ <P>
+ </P>
+ <DIV CLASS="c2">
+ <IMG ALT="error-file:TidyOut.log" SRC="img00002.gif"><A NAME="_Ref352404075">Figure 2</A>
+ </DIV>
+ <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>
+ <P>
+ The different FastCGI packet types are:
+ </P>
+ <TABLE>
+ <TR>
+ <TD WIDTH="186">
+ <TT CLASS="c3">FCGI_PARAMS</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 CLASS="c3">FCGI_STDIN</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 CLASS="c3">FCGI_DATA</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 CLASS="c3">FCGI_STDOUT</TT>
+ </TD>
+ <TD WIDTH="228">
+ Used to send standard output from the application to the Web server.
+ </TD>
+ </TR>
+ <TR>
+ <TD WIDTH="186">
+ <TT CLASS="c3">FCGI_STDERR</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 CLASS="c3">FCGI_END_REQUEST</TT>
+ </TD>
+ <TD WIDTH="228">
+ Ends the request (can be sent by either the server or the application).
+ </TD>
+ </TR>
+ </TABLE>
+ <P>
+ </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.
+ </P>
+ <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":
+ </P>
+ <UL>
+ <LI>
+ <B>Responder.</B> This is the basic FastCGI role, and corresponds to the simple functionality offered by
+ CGI today.
+ </LI>
+ <LI>
+ <B>Filter.</B> The FastCGI application filters the requested Web server file before sending it to the
+ client.
+ </LI>
+ <LI>
+ <B>Authorizer.</B> The FastCGI program performs an access control decision for the request (such as
+ performing a username/password database lookup).
+ </LI>
+ </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>
+ <P>
+ The roles are described in more detail in the following sections.
+ </P>
+ <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).
+ </P>
+ <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>
+ <P>
+ Let's assume that the Web server is configured so that all files with the .<TT CLASS="c3">sgml</TT>
+ extension are processed by a SGML-to-HTML FastCGI filter application, and the user accesses the following URL:
+ </P>
+ <P>
+ <TT CLASS="c3">/document.sgml</TT>
+ </P>
+ <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>
+ <P>
+ </P>
+ <DIV CLASS="c2">
+ <IMG ALT="error-file:TidyOut.log" SRC="img00003.gif"><A NAME="_Ref352560526">Figure 3</A>
+ </DIV>
+ <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>
+ <P>
+ The Filter role is useful for:
+ </P>
+ <UL>
+ <LI>
+ On-the-fly format conversions
+ </LI>
+ <LI>
+ Dynamic documents (such as documents with embedded SQL queries, or dynamic advertisement insertion)
+ </LI>
+ <LI>
+ Applying a standard template: headers, footers, and backgrounds
+ </LI>
+ </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>
+ <P>
+ The Authorizer role is useful for:
+ </P>
+ <UL>
+ <LI>
+ Access control based on username and password, where the user information is looked up in an external
+ database.
+ </LI>
+ <LI>
+ Complex access policies, such as time-of-day based access.
+ </LI>
+ <LI>
+ Smart-card challenge/response authentication.
+ </LI>
+ <LI>
+ Dynamic redirects, where the user is sent to different pages based on the request profile.
+ </LI>
+ </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>
+ <P>
+ The application library provides a replacement for the C language standard I/O (stdio) routines, such as <TT
+ CLASS="c3">printf()</TT> and <TT CLASS="c3">gets()</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>
+ <P>
+ This approach has several benefits:
+ </P>
+ <UL>
+ <LI>
+ Developers don't have to learn a new API to develop FastCGI applications.
+ </LI>
+ <LI>
+ Existing CGI programs can be migrated with minimal source changes (CGI migration is described in more
+ detail in the following section).
+ </LI>
+ <LI>
+ FastCGI interpreters for Perl, Tcl, and other interpreted languages can be built without modifying the
+ interpreter source code.
+ </LI>
+ </UL>
+ <P>
+ Here's a simple FastCGI application:
+ </P>
+ <BR>
+ <BR>
<PRE>
#include <fcgi_stdio.h>
{
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++);
+ 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
+ <P>
+ 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>
+ <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.
+ </P>
+ <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>
+ <P>
+ <I>Initialize application;<BR>
+ </I> <TT>while(FCGI_Accept() >= 0) {</TT><BR>
+ <I>Process request</I>;<BR>
+ <TT>}</TT>
+ </P>
+ <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>
+ <P>
+ After migration, developers can clean up their FastCGI applications for best performance:
+ </P>
+ <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>
+ <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>
+ <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.
+ </LI>
+ </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.
+ </P>
+ <H2>
+ 5. FastCGI in the Open Market WebServer
+ </H2>
+ <P>
+ This section describes the FastCGI support in the following Open Market server products:
+ </P>
+ <UL>
+ <LI>
+ Open Market WebServer V2.0
+ </LI>
+ <LI>
+ Open Market Secure WebServer V2.0
+ </LI>
+ <LI>
+ Open Market Secure WebServer (Global) V2.0
+ </LI>
+ </UL>
+ <P>
+ For more information about FastCGI support, see the <I>Open Market WebServer Installation and Configuration
+ Guide</I>.
+ </P>
+ <H3>
+ Server Configuration
+ </H3>
+ <P>
+ FastCGI applications are configured with the server's configuration file. Configuration has two parts.
+ </P>
+ <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:
+ </P>
+ <UL>
+ <LI>
+ The pathname of the application executable.
+ </LI>
+ <LI>
+ Any arguments and environment variables to pass to the process at startup.
+ </LI>
+ <LI>
+ The number of processes to run.
+ </LI>
+ </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>
+ <P>
+ The second configuration step is mapping the application class to a role:
+ </P>
+ <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 <SPAN CLASS="c4">/rollcall/</SPAN> might be handled by
+ the employee database application.
+ </LI>
+ <LI>
+ For filter roles, the administrator configures a file extension to be handled by a filter application. For
+ example, all files with the <SPAN CLASS="c4">.sql</SPAN> extension could be handled by a SQL query lookup
+ filter.
+ </LI>
+ <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.
+ </LI>
+ </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>
+ <P>
+ The WebServer treats any file with the extension <SPAN CLASS="c4">.fcg</SPAN> 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.
+ </P>
+ <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>
+ <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).-->
+ </P>
+ <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.
+ </P>
+ <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.
+ </P>
+ <TABLE BORDERCOLOR="#000000" BORDER="2">
+ <TR>
+ <TD WIDTH="72">
+ <DIV CLASS="c5">
+ Static file
+ </DIV>
+ </TD>
+ <TD WIDTH="180">
+ <DIV CLASS="c5">
+ 21ms + 0.19ms per Kbyte
+ </DIV>
+ </TD>
+ </TR>
+ <TR>
+ <TD WIDTH="72">
+ <DIV CLASS="c5">
+ FastCGI
+ </DIV>
+ </TD>
+ <TD WIDTH="180">
+ <DIV CLASS="c5">
+ 22ms + 0.28ms per Kbyte
+ </DIV>
+ </TD>
+ </TR>
+ <TR>
+ <TD WIDTH="72">
+ <DIV CLASS="c5">
+ CGI
+ </DIV>
+ </TD>
+ <TD WIDTH="180">
+ <DIV CLASS="c5">
+ 59ms + 0.37ms per Kbyte
+ </DIV>
+ </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>
+ <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:
+ </P>
+ <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.-->
+ </P>
+ <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. -->
+ </P>
+ <H2>
+ 8. For More Information
+ </H2>
+ <P>
+ For more information about Open Market and our products, visit our Web site at:<SPAN CLASS=
+ "c4">http://www.openmarket.com/</SPAN>
+ </P>
+ <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:<SPAN CLASS=
+ "c4">http://www.openmarket.com/fastcgi/</SPAN>
+ </P>
+ </BODY>
+</HTML>
+
projects / catagits/fcgi2.git / blobdiff