Re: FastCGI with and/or I/O Multiplexing?

David Crane (
Fri, 26 Jul 96 14:09:54 EDT

Date: Fri, 26 Jul 96 14:09:54 EDT
From: (David Crane)
Message-Id: <>
Subject: Re: FastCGI with and/or I/O Multiplexing?

Mark Brown wrote:
> See for a message
> from Lincoln D. Stein on his plans for's coexistence with
> FastCGI.  I don't have any newer info on that.
Until the next release, you can get coexistance with one line
of code, as explained in 

> The current fastcgi libraries don't support I/O multiplexing with
> select.  I have some code sketches for this, but nothing working.
> The message
> contains a good summary of the issues.

Yes, I had just read that post moments before your reply to me
arrived!  (By the way, you write very well).

> [...]
> Do I understand correctly that your dispatch script allows browsers to
> connect directly, without going through the Web server?  How do you
> address the security issues raised by such direct connections?
Yes, the old application worked exactly as you describe.  It was for
use only within the company, so security wasn't an issue.  The new 
version will be accessed from outside, and it will be structured 
differently.  I don't know if any of the following details are relevant
or even of interest (having little to do with fastcgi), but here goes:

Web browsers will contact the standard port 80 on a server that
bridges our firewall.  A small cgi script will be executed, which will
connect across our firewall to one of my compute servers.  I certainly
have no security expertese, so what follows makes me nervous.

An initial request (one that starts a "session") will cause the script
to pick a host:port from some configuration data, and connect there.
I won't be using fastcgi for this connection:  I plan to have inetd
waiting on that port, forking my dispatch script for the connection.
The new dispatch script will change the SRC urls in the framesets
differently.  Instead of a direct connection to the compute server, 
they will connect to the web server, to the same cgi script as the 
initial request.  The path info will tell that script which host:port 
to connect to get the content document.

Fastcgi comes into play inside the application scripts.  Probably, I
will use Unix domain sockets for the dispatch script to connect to a
running application script.  The path info on the initial request
indicates which application to call.  I will simply wrap each app in
a fastcgi loop, with an undef(@CGI::QUERY_STATE) at the bottom.

David Crane
Salomon Brothers, Inc.