-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">\r
-<HTML>\r
- <HEAD>\r
- <TITLE>\r
- FastCGI: A High-Performance Gateway Interface\r
- </TITLE>\r
-<STYLE TYPE="text/css">\r
- h5.c2 {text-align: center}\r
- div.c1 {text-align: center}\r
-</STYLE>\r
- </HEAD>\r
- <BODY>\r
- <DIV CLASS="c1">\r
- <H2>\r
- FastCGI: A High-Performance Gateway Interface\r
- </H2>\r
- Position paper for the workshop "Programming the Web - a search for APIs",<BR>\r
- Fifth International World Wide Web Conference, 6 May 1996, Paris, France.<BR>\r
- <P>\r
- Mark R. Brown<BR>\r
- Open Market, Inc.<BR>\r
- </P>\r
- <P>\r
- 2 May 1996<BR>\r
- </P>\r
- </DIV>\r
- <P>\r
- </P>\r
- <H5 CLASS="c2">\r
- Copyright © 1996 Open Market, Inc. 245 First Street, Cambridge, MA 02142 U.S.A.<BR>\r
- Tel: 617-621-9500 Fax: 617-621-1703 URL: <A HREF=\r
- "http://www.openmarket.com/">http://www.openmarket.com/</A><BR>\r
- </H5>\r
- <HR>\r
- <H3>\r
- Abstract\r
- </H3>\r
- <P>\r
- FastCGI is a fast, open, and secure Web server interface that solves the performance problems inherent in CGI\r
- without introducing any of the new problems associated with writing applications to lower-level Web server\r
- APIs. Modules to support FastCGI can be plugged into Web server APIs such as Apache API, NSAPI, and ISAPI. Key\r
- considerations in designing FastCGI included minimizing the cost of migrating CGI applications (including\r
- applications written in popular scripting languages such as Perl), supporting both single-threaded and\r
- multi-threaded application programming, supporting distributed configurations for scaling and high\r
- availability, and generalizing the roles that gateway applications can play beyond CGI's\r
- "responder" role.\r
- </P>\r
- <P>\r
- For more information on FastCGI, including an interface specification and a module for the Apache server,\r
- visit the <A HREF="http://www.fastcgi.com/">www.fastcgi.com Web site</A>.\r
- </P>\r
- <H3>\r
- 1. Introduction\r
- </H3>\r
- <P>\r
- The surge in the use of the Web by business has created great demand for applications that create dynamic\r
- content. These applications allow businesses to deliver products, services, and messages whose shape and\r
- content are influenced by interaction with and knowledge of users.\r
- </P>\r
- <P>\r
- This move towards dynamic Web content has highlighted the performance limits of CGI (Common Gateway\r
- Interface). In response there has been a proliferation of Web server APIs. These APIs address some (though not\r
- all) of the performance problems with CGI, but are not designed to meet the need of business applications.\r
- When applied to business applications, Web server APIs suffer from these problems:\r
- </P>\r
- <UL>\r
- <LI>\r
- <B>Complexity.</B> Server APIs introduce a steep learning curve, with increased implementation and\r
- maintenance costs.\r
- </LI>\r
- <LI>\r
- <B>Language dependence.</B> Applications have to be written in a language supported by the server API\r
- (usually C/C++). Perl, the most popular language for CGI programs, can't be used with any existing\r
- server API.\r
- </LI>\r
- <LI>\r
- <B>No process isolation.</B> Since the applications run in the server's address space, buggy\r
- applications can corrupt the core server (or each other). A malicious or buggy application can compromise\r
- server security, and bugs in the core server can corrupt applications.\r
- </LI>\r
- <LI>\r
- <B>Proprietary.</B> Coding your application to a particular API locks you into a particular server.\r
- </LI>\r
- <LI>\r
- <B>Tie-in to server architecture.</B> API applications have to share the same architecture as the server:\r
- If the Web server is multi-threaded, the application has to be thread-safe. If the Web server has\r
- single-threaded processes, multi-threaded applications don't gain any performance advantage. Also, when\r
- the server's architecture changes, the API will usually have to change, and applications will have to\r
- be adapted or rewritten.\r
- </LI>\r
- </UL>\r
- <P>\r
- Web server APIs are suitable for applications that require an intimate connection to the core Web server, such\r
- as security protocols. But using a Web server API for a Web business application would be much like using an\r
- old-fashioned TP monitor, which required linking applications right into the monitor, for a modern business\r
- transaction processing application. The old-fashioned solution suffers a huge development and maintenance cost\r
- penalty because it ignores 30 years of progress in computing technology, and may end up providing inferior\r
- performance to boot. Nobody uses the old technology unless they are already locked into it.\r
- </P>\r
- <P>\r
- FastCGI is best viewed as a new implementation of CGI, designed to overcome CGI's performance problems.\r
- The major implementation differences are:\r
- </P>\r
- <UL>\r
- <LI>\r
- FastCGI processes are persistent: after finishing a request, they wait for a new request instead of\r
- exiting.\r
- </LI>\r
- <LI>\r
- Instead of using operating system environment variables and pipes, the FastCGI protocol multiplexes the\r
- environment information, standard input, output, and error over a single full-duplex connection. This\r
- allows FastCGI programs to run on remote machines, using TCP connections between the Web server and the\r
- FastCGI application.\r
- </LI>\r
- </UL>\r
- <P>\r
- FastCGI communicates the exact same information as CGI in a different way. Because FastCGI <I>is</I> CGI, and\r
- like CGI runs applications in separate processes, it suffers none of the server API problems listed above.\r
- </P>\r
- <H3>\r
- 2. Migration from CGI\r
- </H3>\r
- <P>\r
- Open Market has developed a FastCGI application library that implements the FastCGI protocol, hiding the\r
- protocol details from the developer. This library, which is freely available, makes writing FastCGI programs\r
- as easy as writing CGI applications.\r
- </P>\r
- <P>\r
- The application library provides replacements for the C language standard I/O (stdio) routines such as\r
- <TT>printf()</TT> and <TT>gets()</TT>. The library converts references to environment variables, standard\r
- input, standard output, and standard error to the FastCGI protocol. References to other files "fall\r
- through" to the underlying operating system standard I/O routines. This approach has several benefits:\r
- </P>\r
- <UL>\r
- <LI>\r
- Developers don't have to learn a new API to develop FastCGI applications.\r
- </LI>\r
- <LI>\r
- Existing CGI programs can be migrated with minimal source changes.\r
- </LI>\r
- <LI>\r
- FastCGI interpreters for Perl, Tcl, and other interpreted languages can be built without modifying the\r
- interpreter source code.\r
- </LI>\r
- </UL>\r
- <P>\r
- Here's a simple FastCGI application:\r
- </P>\r
- <BR>\r
- <BR>\r
-<PRE>\r
- #include <fcgi_stdio.h>\r
-\r
- void main(void)\r
- {\r
- int count = 0;\r
- while(FCGI_Accept() >= 0) {\r
- printf("Content-type: text/html\r\n");\r
- printf("\r\n");\r
- printf("Hello world!<br>\r\n");\r
- printf("Request number %d.", count++);\r
- }\r
- exit(0);\r
- }\r
-</PRE>\r
- <P>\r
- This application returns a "Hello world" HTML response to the client. It also keeps a counter of the\r
- number of times it has been accessed, displaying the value of the counter at each request. The\r
- <TT>fcgi_stdio.h</TT> header file provides the FastCGI replacement routines for the C standard I/O library.\r
- The <TT>FCGI_Accept()</TT> routine accepts a new request from the Web server.\r
- </P>\r
- <P>\r
- The application library was designed to make migration of existing CGI programs as simple as possible. Many\r
- applications can be converted by adding a loop around the main request processing code and recompiling with\r
- the FastCGI application library. To ease migration to FastCGI, executables built with the application library\r
- can run as either CGI or FastCGI programs, depending on how they are invoked. The library detects the\r
- execution environment and automatically selects FastCGI or regular I/O routines, as appropriate.\r
- </P>\r
- <P>\r
- Applications written in Perl, Tcl, and other scripting languages can be migrated by using a language\r
- interpreter built with the application library. FastCGI-integrated Tcl and Perl interpreters for popular Unix\r
- platforms are available from the <I>www.fastcgi.com</I> Web site. The interpreters are backward-compatible:\r
- They can run standard Tcl and Perl applications.\r
- </P>\r
- <H3>\r
- 3. Single-threaded and multi-threaded applications\r
- </H3>\r
- <P>\r
- FastCGI gives developers a free choice of whether to develop applications in a single-threaded or\r
- multi-threaded style. The FastCGI interface supports multi-threading in two ways:\r
- </P>\r
- <UL>\r
- <LI>\r
- Applications can accept concurrent Web server connections to provide concurrent requests to multiple\r
- application threads.\r
- </LI>\r
- <LI>\r
- Applications can accept multiplexed Web server connections, in which concurrent requests are communicated\r
- over a single connection to multiple application threads.\r
- </LI>\r
- </UL>\r
- <P>\r
- Multi-threaded programming is complex -- concurrency makes programs difficult to test and debug -- so many\r
- developers will prefer to program in the familiar single-threaded style. By having several concurrent\r
- processes running the same application it is often possible to achieve high performance with single-threaded\r
- programming.\r
- </P>\r
- <P>\r
- The FastCGI interface allows Web servers to implement <I>session affinity</I>, a feature that allows\r
- applications to maintain caches of user-related data. With session affinity, when several concurrent processes\r
- are running the same application, the Web server routes all requests from a particular user to the same\r
- application process. Web server APIs don't provide this functionality to single-threaded applications, so\r
- the performance of an API-based application is often inferior to the performance of the corresponding FastCGI\r
- application.\r
- </P>\r
- <H3>\r
- 4. Distributed FastCGI\r
- </H3>\r
- <P>\r
- Because FastCGI can communicate over TCP/IP connections, it supports configurations in which applications run\r
- remotely from the Web server. This can provide scaling, load balancing, high availability, and connections to\r
- systems that don't have Web servers.\r
- </P>\r
- <P>\r
- Distributed FastCGI can also provide security advantages. A Web server outside a corporate firewall can\r
- communicate through the firewall to internal databases. For instance, an application might need to\r
- authenticate incoming users as customers in order to give access to certain documents on the external Web\r
- site. With FastCGI this authentication can be done without replicating data and without compromising security.\r
- </P>\r
- <H3>\r
- 5. Roles\r
- </H3>\r
- <P>\r
- A problem with CGI is its limited functionality: CGI programs can only provide responses to requests. FastCGI\r
- provides expanded functionality with support for three different application "roles":\r
- </P>\r
- <UL>\r
- <LI>\r
- <B>Responder.</B> This is the basic FastCGI role, and corresponds to the simple functionality offered by\r
- CGI today.\r
- </LI>\r
- <LI>\r
- <B>Filter.</B> The FastCGI application filters the requested Web server file before sending it to the\r
- client.\r
- </LI>\r
- <LI>\r
- <B>Authorizer.</B> The FastCGI program performs an access control decision for the request (such as\r
- performing a username/password database lookup).\r
- </LI>\r
- </UL>\r
- <P>\r
- Other roles will be defined in the future. For instance, a "logger" role would be useful, where the\r
- FastCGI program would receive the server's log entries for real-time processing and analysis.\r
- </P>\r
- <H3>\r
- 6. Conclusions\r
- </H3>\r
- <P>\r
- Today's Web business applications need a platform that's fast, open, maintainable, straightforward,\r
- stable, and secure. FastCGI's design meets these requirements, and provides a logical migration path from\r
- the proven and widely deployed CGI technology. This allows developers to take advantage of FastCGI's\r
- benefits without losing their existing investment in CGI applications.\r
- </P>\r
- <P>\r
- For more information about FastCGI, visit the <A HREF="http://www.fastcgi.com/">www.fastcgi.com Web site</A>.\r
- </P>\r
- </BODY>\r
-</HTML>\r
-\r
+<!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>
+
+ 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>
+ <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