[catagits/fcgi2.git] / doc / www5-api-workshop.html

<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 &copy; 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 &quot;fall through&quot; 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>
<PRE>
    #include &lt;fcgi_stdio.h&gt;

    void main(void)
    {
        int count = 0;
        while(FCGI_Accept() &gt;= 0) {
            printf("Content-type: text/html\r\n");
            printf("\r\n");
            printf("Hello world!&lt;br&gt;\r\n");
            printf("Request number %d.", count++);
        }
        exit(0);
    }
</PRE>
This application returns a &quot;Hello world&quot;
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 &quot;roles&quot;:
<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 &quot;logger&quot; 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>
</HTML>
Commit	Line	Data
0198fd3c	1	<html>
	2	<head>
	3	<title>FastCGI: A High-Performance Gateway Interface</title>
	4	</head>
	5
	6	<body>
	7	<center>
	8	<h2>FastCGI: A High-Performance Gateway Interface</h2>
	9	Position paper for the workshop
	10	"Programming the Web - a search for APIs",<br>
	11	Fifth International World Wide Web Conference,
	12	6 May 1996, Paris, France.<br>
	13	<p>
	14	Mark R. Brown<br>
	15	Open Market, Inc.<br>
	16	<p>
	17
	18	2 May 1996<br>
	19	</center>
	20	<p>
	21
	22	<h5 align=center>
	23	Copyright © 1996 Open Market, Inc. 245 First Street, Cambridge,
	24	MA 02142 U.S.A.<br>
	25	Tel: 617-621-9500 Fax: 617-621-1703 URL:
	26	<a href="http://www.openmarket.com/">http://www.openmarket.com/</a><br>
	27	</h5>
	28	<hr>
	29
	30
	31	<H3>Abstract</H3>
	32
	33	FastCGI is a fast, open, and secure Web server interface that
	34	solves the performance problems inherent in CGI without
	35	introducing any of the new problems associated with writing applications
	36	to lower-level Web server APIs. Modules to support FastCGI can
	37	be plugged into Web server APIs such as Apache API, NSAPI, and ISAPI.
	38	Key considerations in designing FastCGI included minimizing the cost of
	39	migrating CGI applications (including applications written in popular
	40	scripting languages such as Perl), supporting both single-threaded and
	41	multi-threaded application programming, supporting distributed configurations
	42	for scaling and high availability, and generalizing the roles that
	43	gateway applications can play beyond CGI's "responder" role.<p>
	44
	45	For more information on FastCGI, including an interface specification
	46	and a module for the Apache server, visit the
	47	<a href = "http://www.fastcgi.com/">www.fastcgi.com Web site</a>.
	48
	49
	50	<H3>1. Introduction</H3>
	51
	52	The surge in the use of the Web by business has created great demand
	53	for applications that create dynamic content. These applications
	54	allow businesses to deliver products, services, and messages whose
	55	shape and content are influenced by interaction with and knowledge
	56	of users.
	57
	58	<P> This move towards dynamic Web content has highlighted the performance
	59	limits of CGI (Common Gateway Interface). In response there has been
	60	a proliferation of Web server APIs. These APIs address some (though
	61	not all) of the performance problems with CGI, but are not designed to
	62	meet the need of business applications. When applied to business
	63	applications, Web server APIs suffer from these problems:
	64
65	<UL>
66	<LI><B>Complexity.</B>
67	Server APIs introduce a steep learning curve, with increased
68	implementation and maintenance costs.
69	<LI><B>Language dependence.</B>
70	Applications have to be written in a language supported by the
71	server API (usually C/C++). Perl, the most popular language for
72	CGI programs, can't be used with any existing server API.
73	<LI><B>No process isolation.</B>
74	Since the applications run in the server's address space, buggy
75	applications can corrupt the core server (or each other). A
76	malicious or buggy application can compromise server security, and
77	bugs in the core server can corrupt applications.
78	<LI><B>Proprietary.</B>
79	Coding your application to a particular API locks you into a
80	particular server.
81	<LI><B>Tie-in to server architecture.</B>
82	API applications have to share the same architecture as the server:
83	If the Web server is multi-threaded, the application has to be
84	thread-safe. If the Web server has single-threaded processes,
85	multi-threaded applications don't gain any performance advantage.
86	Also, when the server's architecture changes, the API
87	will usually have to change, and applications will have to be
88	adapted or rewritten.
89	</UL>
90
91	Web server APIs are suitable for applications that require an intimate
92	connection to the core Web server, such as security protocols. But
93	using a Web server API for a Web business application would be much
94	like using an old-fashioned TP monitor, which required linking
95	applications right into the monitor, for a modern business transaction
96	processing application. The old-fashioned solution suffers a huge
97	development and maintenance cost penalty because it ignores 30 years
98	of progress in computing technology, and may end up
99	providing inferior performance to boot. Nobody uses the old technology
100	unless they are already locked into it.
101
102	<p> FastCGI is best viewed as a new implementation of CGI,
103	designed to overcome CGI's performance problems. The major
104	implementation differences are:
105
106	<UL>
107	<LI>FastCGI processes are persistent: after finishing a request,
108	they wait for a new request instead of exiting.
109
110	<LI>Instead of using operating system environment variables and
111	pipes, the FastCGI protocol multiplexes the environment information,
112	standard input, output, and error over a single full-duplex
113	connection. This allows FastCGI programs to run on remote machines,
114	using TCP connections between the Web server and the FastCGI
115	application.
116	</UL>
117
118	<p> FastCGI communicates the exact same information as CGI in a
119	different way. Because FastCGI <i>is</i> CGI, and like CGI runs
120	applications in separate processes, it suffers none of the server API
121	problems listed above.
122
123
124	<H3>2. Migration from CGI</H3>
125
126	Open Market has developed a FastCGI application library
127	that implements the FastCGI protocol, hiding the protocol details
128	from the developer. This library, which is freely available,
129	makes writing FastCGI programs
130	as easy as writing CGI applications.
131
132	<P> The application library provides replacements for the C language
133	standard I/O (stdio) routines such as <TT>printf()</TT> and
134	<TT>gets()</TT>. The library converts references to environment
135	variables, standard input,
136	standard output, and standard error to the FastCGI protocol.
137	References to other files "fall through" to the underlying
138	operating system standard I/O routines. This approach has several benefits:
139
140	<UL>
141	<LI>Developers don't have to learn a new API to develop FastCGI
142	applications.
143
144	<LI>Existing CGI programs can be migrated with minimal
145	source changes.
146
147	<LI>FastCGI interpreters for Perl, Tcl, and other interpreted
148	languages can be built without modifying the interpreter source
149	code.
150	</UL>
151
152	<P>
153	Here's a simple FastCGI application:<P>
154	<PRE>
155	#include <fcgi_stdio.h>
156
157	void main(void)
158	{
159	int count = 0;
160	while(FCGI_Accept() >= 0) {
161	printf("Content-type: text/html\r\n");
162	printf("\r\n");
163	printf("Hello world!<br>\r\n");
164	printf("Request number %d.", count++);
165	}
166	exit(0);
167	}
168	</PRE>
169	This application returns a "Hello world"
170	HTML response to the client. It also keeps a counter of the number
171	of times it has been accessed, displaying the value of the counter
172	at each request. The <TT>fcgi_stdio.h</TT>
173	header file provides the FastCGI replacement routines for the
174	C standard I/O library. The <TT>FCGI_Accept()</TT>
175	routine accepts a new request from the Web server.</FONT>
176
177	<p> The application library was designed to make migration
178	of existing CGI programs as simple as possible. Many applications
179	can be converted by adding a loop around the main request processing
180	code and recompiling with the FastCGI application library.
181	To ease migration to FastCGI, executables built with
182	the application library can run as either CGI or FastCGI programs,
183	depending on how they are invoked. The library detects the execution
184	environment and automatically selects FastCGI or regular I/O routines,
185	as appropriate.
186
187	<P> Applications written in Perl, Tcl, and other scripting
188	languages can be migrated by using a language interpreter built
189	with the application library. FastCGI-integrated Tcl and Perl
190	interpreters for popular Unix platforms are available from
191	the <i>www.fastcgi.com</i> Web site. The interpreters are
192	backward-compatible: They can run standard Tcl and Perl applications.
193
194
195	<H3>3. Single-threaded and multi-threaded applications</H3>
196
197	FastCGI gives developers a free choice of whether to develop
198	applications in a single-threaded or multi-threaded style.
199	The FastCGI interface supports multi-threading in two ways:
200
201	<ul>
202	<li> Applications can accept concurrent Web server connections
203	to provide concurrent requests to multiple application threads.
204
205	<li> Applications can accept multiplexed Web server connections,
206	in which concurrent requests are communicated over a single
207	connection to multiple application threads.
208	</ul>
209
210	<p> Multi-threaded programming is complex -- concurrency makes
211	programs difficult to test and debug -- so many developers will prefer
212	to program in the familiar single-threaded style. By having several
213	concurrent processes running the same application it is often possible
214	to achieve high performance with single-threaded programming.
215
216	<p> The FastCGI interface allows Web servers to implement <i>session
217	affinity</i>, a feature that allows applications to maintain
218	caches of user-related data. With session affinity, when several
219	concurrent processes are running the same application, the Web
220	server routes all requests from a particular user to the same
221	application process. Web server APIs don't provide this functionality
222	to single-threaded applications, so the performance of an API-based
223	application is often inferior to the performance of the
224	corresponding FastCGI application.
225
226
227	<H3>4. Distributed FastCGI</H3>
228
229	Because FastCGI can communicate over TCP/IP connections, it supports
230	configurations in which applications run remotely from
231	the Web server. This can provide scaling, load balancing,
232	high availability, and connections to systems that don't have
233	Web servers.
234
235	<p> Distributed FastCGI can also provide security advantages.
236	A Web server outside a corporate firewall can communicate
237	through the firewall to internal databases. For instance,
238	an application might need to authenticate incoming users
239	as customers in order to give access to certain documents
240	on the external Web site. With FastCGI this authentication
241	can be done without replicating data and without compromising
242	security.
243
244
245	<H3>5. Roles</H3>
246
247	A problem with CGI is its limited functionality:
248	CGI programs can only provide responses to requests.
249	FastCGI provides expanded functionality with support for three
250	different application "roles":
251	<UL>
252
253	<LI><B>Responder.</B> This is the basic FastCGI role, and
254	corresponds to the simple functionality offered by CGI today.
255
256	<LI><B>Filter.</B> The FastCGI application filters the requested Web
257	server file before sending it to the client.
258
259	<LI><B>Authorizer.</B> The FastCGI program performs an access
260	control decision for the request (such as performing a
261	username/password database lookup).
262
263	</UL>
264
265	<P>
266	Other roles will be defined in the future. For instance,
267	a "logger" role would be useful, where the FastCGI program
268	would receive the server's log entries for real-time processing
269	and analysis.
270
271
272	<H3>6. Conclusions</H3>
273
274	<P>Today's Web business applications need a platform that's fast,
275	open, maintainable, straightforward, stable, and secure. FastCGI's
276	design meets these requirements, and provides a logical migration
277	path from the proven and widely deployed CGI technology. This allows
278	developers to take advantage of FastCGI's benefits without losing
279	their existing investment in CGI applications.
280
281	<P>For more information about FastCGI, visit the
282	<a href = "http://www.fastcgi.com/">www.fastcgi.com Web site</a>.
283
284
285	</BODY>
286	</HTML>