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