doc/www5-api-workshop.html

   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 &copy; 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 &quot;fall through&quot; 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 &lt;fcgi_stdio.h&gt;
 156
 157     void main(void)
 158     {
 159         int count = 0;
 160         while(FCGI_Accept() &gt;= 0) {
 161             printf("Content-type: text/html\r\n");
 162             printf("\r\n");
 163             printf("Hello world!&lt;br&gt;\r\n");
 164             printf("Request number %d.", count++);
 165         }
 166         exit(0);
 167     }
 168 </PRE>
 169 This application returns a &quot;Hello world&quot;
 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 &quot;roles&quot;:
 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 &quot;logger&quot; 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>