Re: FastCGI with CGI.pm and/or I/O Multiplexing?

Mark Brown (mbrown@OpenMarket.com)
Fri, 26 Jul 1996 11:11:54 -0400

Message-Id: <199607261511.LAA27094@breckenridge.openmarket.com>
To: fastcgi-developers@OpenMarket.com
Subject: Re: FastCGI with CGI.pm and/or I/O Multiplexing? 
In-Reply-To: <9607261344.AA25300@mr_magoo.sbi.com> 
Date: Fri, 26 Jul 1996 11:11:54 -0400
From: Mark Brown <mbrown@OpenMarket.com>


David Crane <dcrane@mr_magoo.sbi.com> asks:

    [1] Can I mix fastcgi and CGI.pm in one perl script?
    [2] Can I mix fastcgi and I/O multiplexing with the select perl (system)
        call in another perl script?

See http://www.fastcgi.com/mail-archive/0085.html for a message
from Lincoln D. Stein on his plans for CGI.pm's coexistence with
FastCGI.  I don't have any newer info on that.

The current fastcgi libraries don't support I/O multiplexing with
select.  I have some code sketches for this, but nothing working.
The message http://www.fastcgi.com/mail-archive/0073.html
contains a good summary of the issues.

The structure you describe also requires a FastCGI *client* library,
i.e. something that allows an application to play the role that the
Web server ususally plays in a FastCGI connection.  There is code in
cgi-fcgi/cgi-fcgi.c that could be lifted and generalized, but somebody
needs to step up to this.

I don't know enough about your application to know if the following is
good suggestion or not, but here goes: You could take the
state-management code from your dispatch script and turn it into a
package with a simple interface.  Then change your app scripts to call
this package, and run the app scripts a standard FastCGI programs with
session affinity.  The examples/sample-store.c application, though
written in C not Perl, might give you some ideas.

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?

    --mark