recently-asked FastCGI questions

Mark Brown (
Wed, 05 Jun 1996 18:42:00 -0400

Message-Id: <>
Subject: recently-asked FastCGI questions
Date: Wed, 05 Jun 1996 18:42:00 -0400
From: Mark Brown <>

Q: Why does the FastCGI protocol include a complex feature like
connection multiplexing that the API can't take advantage of?

A: The FastCGI protocol is more basic than the current application
library API.  There will be many application libraries with different
levels of aspiration.  Some, like the current fcgi_stdio, will be very
simple and won't fully exploit the protocol.  But others are bound to
come along that provide a more concurrent API and can take advantage
of connection multiplexing.  Applications based on the current
libraries will continue to run without change.

Q: Can I configure a Web server to start a FastCGI application for
each authenticated user?  I want each user to be connected to his or
her own copy of the application.  That way I can easily create
persistent database connections without having to write complicated
code to multiplex users.

A: None of the Web servers directly supports this mode of operation.

There's a way to do it with the Open Market server using the
Authorizer role to assign processes to users.  This may be
a good way of porting existing stateful applications to the Web.

Another way to go would be to modify cgi-fcgi to support this mode of
operation.  cgi-fcgi is a small, self-contained program so it is
easier to experiment with cgi-fcgi than with a Web server module.

For new applications you may want to avoid this technique because
it won't scale very well: The processes will spend most of their
time idle.  Multiplexing a process between users isn't so
difficult once you have a reliable session ID to work with.
Open Market's server provides this with its bundled ticketing
extension, or you can roll your own.

Q: Do the Perl 5 CGI::* modules work with FastCGI?

A: I don't know.  Has anybody out there tried them together?