-<html>
-<head>
-<title>FastCGI: A High-Performance Gateway Interface</title>
-</head>
-
-<body>
-<center>
-<h2>FastCGI: A High-Performance Gateway Interface</h2>
-Position paper for the workshop
-"Programming the Web - a search for APIs",<br>
-Fifth International World Wide Web Conference,
-6 May 1996, Paris, France.<br>
-<p>
-Mark R. Brown<br>
-Open Market, Inc.<br>
-<p>
-
-2 May 1996<br>
-</center>
-<p>
-
-<h5 align=center>
-Copyright © 1996 Open Market, Inc. 245 First Street, Cambridge,
- MA 02142 U.S.A.<br>
-Tel: 617-621-9500 Fax: 617-621-1703 URL:
- <a href="http://www.openmarket.com/">http://www.openmarket.com/</a><br>
-</h5>
-<hr>
-
-
-<H3>Abstract</H3>
-
-FastCGI is a fast, open, and secure Web server interface that
-solves the performance problems inherent in CGI without
-introducing any of the new problems associated with writing applications
-to lower-level Web server APIs. Modules to support FastCGI can
-be plugged into Web server APIs such as Apache API, NSAPI, and ISAPI.
-Key considerations in designing FastCGI included minimizing the cost of
-migrating CGI applications (including applications written in popular
-scripting languages such as Perl), supporting both single-threaded and
-multi-threaded application programming, supporting distributed configurations
-for scaling and high availability, and generalizing the roles that
-gateway applications can play beyond CGI's "responder" role.<p>
-
-For more information on FastCGI, including an interface specification
-and a module for the Apache server, visit the
-<a href = "http://www.fastcgi.com/">www.fastcgi.com Web site</a>.
-
-
-<H3>1. Introduction</H3>
-
-The surge in the use of the Web by business has created great demand
-for applications that create dynamic content. These applications
-allow businesses to deliver products, services, and messages whose
-shape and content are influenced by interaction with and knowledge
-of users.
-
-<P> This move towards dynamic Web content has highlighted the performance
-limits of CGI (Common Gateway Interface). In response there has been
-a proliferation of Web server APIs. These APIs address some (though
-not all) of the performance problems with CGI, but are not designed to
-meet the need of business applications. When applied to business
-applications, Web server APIs suffer from these problems:
-
-<UL>
-<LI><B>Complexity.</B>
- Server 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
- server API (usually C/C++). Perl, the most popular language for
- CGI programs, can't be used with any existing server API.
-<LI><B>No process isolation.</B>
- 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.
-<LI><B>Proprietary.</B>
- Coding your application to a particular API locks you into a
- particular 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 server's architecture changes, the API
- will usually have to change, and applications will have to be
- adapted or rewritten.
-</UL>
-
-Web server APIs are suitable for applications that require an intimate
-connection to the core Web server, such as security protocols. But
-using a Web server API for a Web business application would be much
-like using an old-fashioned TP monitor, which required linking
-applications right into the monitor, for a modern business transaction
-processing application. The old-fashioned solution suffers a huge
-development and maintenance cost penalty because it ignores 30 years
-of progress in computing technology, and may end up
-providing inferior performance to boot. Nobody uses the old technology
-unless they are already locked into it.
-
-<p> FastCGI is best viewed as a new implementation of CGI,
-designed to overcome CGI's performance problems. The major
-implementation differences are:
-
-<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> FastCGI communicates the exact same information as CGI in a
-different way. Because FastCGI <i>is</i> CGI, and like CGI runs
-applications in separate processes, it suffers none of the server API
-problems listed above.
-
-
-<H3>2. Migration from CGI</H3>
-
-Open Market has developed a FastCGI application library
-that implements the FastCGI protocol, hiding the protocol details
-from the developer. This library, which is freely available,
-makes writing FastCGI programs
-as easy as writing CGI applications.
-
-<P> The application library provides replacements for the C language
-standard I/O (stdio) routines such as <TT>printf()</TT> and
-<TT>gets()</TT>. The library converts references to environment
-variables, 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. 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.
-
- <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>
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE>
+ FastCGI: A High-Performance Gateway Interface
+ </TITLE>
+<STYLE TYPE="text/css">
+ h5.c2 {text-align: center}
+ div.c1 {text-align: center}
+</STYLE>
+ </HEAD>
+ <BODY>
+ <DIV CLASS="c1">
+ <H2>
+ FastCGI: A High-Performance Gateway Interface
+ </H2>
+ Position paper for the workshop "Programming the Web - a search for APIs",<BR>
+ Fifth International World Wide Web Conference, 6 May 1996, Paris, France.<BR>
+ <P>
+ Mark R. Brown<BR>
+ Open Market, Inc.<BR>
+ </P>
+ <P>
+ 2 May 1996<BR>
+ </P>
+ </DIV>
+ <P>
+ </P>
+ <H5 CLASS="c2">
+ Copyright © 1996 Open Market, Inc. 245 First Street, Cambridge, MA 02142 U.S.A.<BR>
+ Tel: 617-621-9500 Fax: 617-621-1703 URL: <A HREF=
+ "http://www.openmarket.com/">http://www.openmarket.com/</A><BR>
+ </H5>
+ <HR>
+ <H3>
+ Abstract
+ </H3>
+ <P>
+ FastCGI is a fast, open, and secure Web server interface that solves the performance problems inherent in CGI
+ without introducing any of the new problems associated with writing applications to lower-level Web server
+ APIs. Modules to support FastCGI can be plugged into Web server APIs such as Apache API, NSAPI, and ISAPI. Key
+ considerations in designing FastCGI included minimizing the cost of migrating CGI applications (including
+ applications written in popular scripting languages such as Perl), supporting both single-threaded and
+ multi-threaded application programming, supporting distributed configurations for scaling and high
+ availability, and generalizing the roles that gateway applications can play beyond CGI's
+ "responder" role.
+ </P>
+ <P>
+ For more information on FastCGI, including an interface specification and a module for the Apache server,
+ visit the <A HREF="http://www.fastcgi.com/">www.fastcgi.com Web site</A>.
+ </P>
+ <H3>
+ 1. Introduction
+ </H3>
+ <P>
+ The surge in the use of the Web by business has created great demand for applications that create dynamic
+ content. These applications allow businesses to deliver products, services, and messages whose shape and
+ content are influenced by interaction with and knowledge of users.
+ </P>
+ <P>
+ This move towards dynamic Web content has highlighted the performance limits of CGI (Common Gateway
+ Interface). In response there has been a proliferation of Web server APIs. These APIs address some (though not
+ all) of the performance problems with CGI, but are not designed to meet the need of business applications.
+ When applied to business applications, Web server APIs suffer from these problems:
+ </P>
+ <UL>
+ <LI>
+ <B>Complexity.</B> Server 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 server API
+ (usually C/C++). Perl, the most popular language for CGI programs, can't be used with any existing
+ server API.
+ </LI>
+ <LI>
+ <B>No process isolation.</B> 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.
+ </LI>
+ <LI>
+ <B>Proprietary.</B> Coding your application to a particular API locks you into a particular 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 server's architecture changes, the API will usually have to change, and applications will have to
+ be adapted or rewritten.
+ </LI>
+ </UL>
+ <P>
+ Web server APIs are suitable for applications that require an intimate connection to the core Web server, such
+ as security protocols. But using a Web server API for a Web business application would be much like using an
+ old-fashioned TP monitor, which required linking applications right into the monitor, for a modern business
+ transaction processing application. The old-fashioned solution suffers a huge development and maintenance cost
+ penalty because it ignores 30 years of progress in computing technology, and may end up providing inferior
+ performance to boot. Nobody uses the old technology unless they are already locked into it.
+ </P>
+ <P>
+ FastCGI is best viewed as a new implementation of CGI, designed to overcome CGI's performance problems.
+ The major implementation differences are:
+ </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>
+ FastCGI communicates the exact same information as CGI in a different way. Because FastCGI <I>is</I> CGI, and
+ like CGI runs applications in separate processes, it suffers none of the server API problems listed above.
+ </P>
+ <H3>
+ 2. Migration from CGI
+ </H3>
+ <P>
+ Open Market has developed a FastCGI application library that implements the FastCGI protocol, hiding the
+ protocol details from the developer. This library, which is freely available, makes writing FastCGI programs
+ as easy as writing CGI applications.
+ </P>
+ <P>
+ The application library provides replacements for the C language standard I/O (stdio) routines such as
+ <TT>printf()</TT> and <TT>gets()</TT>. The library converts references to environment variables, 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. 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.
+ </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"
-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. 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.</FONT>
-
-<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.
-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> 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
-the <i>www.fastcgi.com</i> Web site. The interpreters are
-backward-compatible: They can run standard Tcl and Perl applications.
-
-
-<H3>3. Single-threaded and multi-threaded applications</H3>
-
-FastCGI gives developers a free choice of whether to develop
-applications in a single-threaded or multi-threaded style.
-The FastCGI interface supports multi-threading in two ways:
-
-<ul>
- <li> Applications can accept concurrent Web server connections
- to provide concurrent requests to multiple application threads.
-
- <li> Applications can accept multiplexed Web server connections,
- in which concurrent requests are communicated over a single
- connection to multiple application threads.
-</ul>
-
-<p> Multi-threaded programming is complex -- concurrency makes
-programs difficult to test and debug -- so many developers will prefer
-to program in the familiar single-threaded style. By having several
-concurrent processes running the same application it is often possible
-to achieve high performance with single-threaded programming.
-
-<p> The FastCGI interface allows Web servers to implement <i>session
-affinity</i>, a feature that allows applications to maintain
-caches of user-related data. With session affinity, when several
-concurrent processes are running the same application, the Web
-server routes all requests from a particular user to the same
-application process. Web server APIs don't provide this functionality
-to single-threaded applications, so the performance of an API-based
-application is often inferior to the performance of the
-corresponding FastCGI application.
-
-
-<H3>4. Distributed FastCGI</H3>
-
-Because FastCGI can communicate over TCP/IP connections, it supports
-configurations in which applications run remotely from
-the Web server. This can provide scaling, load balancing,
-high availability, and connections to systems that don't have
-Web servers.
-
-<p> Distributed FastCGI can also provide security advantages.
-A Web server outside a corporate firewall can communicate
-through the firewall to internal databases. For instance,
-an application might need to authenticate incoming users
-as customers in order to give access to certain documents
-on the external Web site. With FastCGI this authentication
-can be done without replicating data and without compromising
-security.
-
-
-<H3>5. Roles</H3>
-
-A problem with CGI is its limited functionality:
-CGI programs can only provide 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.
-
-
-<H3>6. Conclusions</H3>
-
-<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 a logical migration
-path from the proven and widely deployed CGI technology. This allows
-developers to take advantage of FastCGI's benefits without losing
-their existing investment in CGI applications.
-
-<P>For more information about FastCGI, visit the
-<a href = "http://www.fastcgi.com/">www.fastcgi.com Web site</a>.
-
-
-</BODY>
+ <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. 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>
+ <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. 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>
+ 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 the <I>www.fastcgi.com</I> Web site. The interpreters are backward-compatible:
+ They can run standard Tcl and Perl applications.
+ </P>
+ <H3>
+ 3. Single-threaded and multi-threaded applications
+ </H3>
+ <P>
+ FastCGI gives developers a free choice of whether to develop applications in a single-threaded or
+ multi-threaded style. The FastCGI interface supports multi-threading in two ways:
+ </P>
+ <UL>
+ <LI>
+ Applications can accept concurrent Web server connections to provide concurrent requests to multiple
+ application threads.
+ </LI>
+ <LI>
+ Applications can accept multiplexed Web server connections, in which concurrent requests are communicated
+ over a single connection to multiple application threads.
+ </LI>
+ </UL>
+ <P>
+ Multi-threaded programming is complex -- concurrency makes programs difficult to test and debug -- so many
+ developers will prefer to program in the familiar single-threaded style. By having several concurrent
+ processes running the same application it is often possible to achieve high performance with single-threaded
+ programming.
+ </P>
+ <P>
+ The FastCGI interface allows Web servers to implement <I>session affinity</I>, a feature that allows
+ applications to maintain caches of user-related data. With session affinity, when several concurrent processes
+ are running the same application, the Web server routes all requests from a particular user to the same
+ application process. Web server APIs don't provide this functionality to single-threaded applications, so
+ the performance of an API-based application is often inferior to the performance of the corresponding FastCGI
+ application.
+ </P>
+ <H3>
+ 4. Distributed FastCGI
+ </H3>
+ <P>
+ Because FastCGI can communicate over TCP/IP connections, it supports configurations in which applications run
+ remotely from the Web server. This can provide scaling, load balancing, high availability, and connections to
+ systems that don't have Web servers.
+ </P>
+ <P>
+ Distributed FastCGI can also provide security advantages. A Web server outside a corporate firewall can
+ communicate through the firewall to internal databases. For instance, an application might need to
+ authenticate incoming users as customers in order to give access to certain documents on the external Web
+ site. With FastCGI this authentication can be done without replicating data and without compromising security.
+ </P>
+ <H3>
+ 5. Roles
+ </H3>
+ <P>
+ A problem with CGI is its limited functionality: CGI programs can only provide 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>
+ <H3>
+ 6. Conclusions
+ </H3>
+ <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 a logical migration path from
+ the proven and widely deployed CGI technology. This allows developers to take advantage of FastCGI's
+ benefits without losing their existing investment in CGI applications.
+ </P>
+ <P>
+ For more information about FastCGI, visit the <A HREF="http://www.fastcgi.com/">www.fastcgi.com Web site</A>.
+ </P>
+ </BODY>
</HTML>
+
projects / catagits/fcgi2.git / blobdiff