In a hurry: probably this is a starting point.

Best regards, Karl

Ok, thanks. I've seen that and pretty much anything similar that can be found with Startpage.com. I can get the environment variables with FCGI no problem.

...
HTTP_CONTENT_TYPE = application/x-www-form-urlencoded
...
[download]

I'm still left wondering how to get at the form data. I'd like the FCGI equivalent of ->params from old, slow CGI to get the idea behind FCGI.

use CGI;

my $q = CGI->new;

# Process an HTTP request
my @values  = $q->multi_param('form_field');

my $value2  = $q->param('param2_name');
[download]

It has to be Fast CGI because that is the API used by nginx and OpenBSD's httpd.

I'm still left wondering how to get at the form data.

heh, use CGI ; its magic like that

Ok. Thanks everybody. The links and the tip helped.

Your question is rather vague – you’ll get better answers if you can be more specific.   I am going to answer, therefore, with a very broad brush.   Although I will speak of Apache, nginix is directly similar.

To start, in the Apache environment there are two modules which support FastCGI:   mod_fcgid and mod_fastcgi.   One is canonical; the other is third-party.   Both should be carefully investigated.

I would also specifically like to alert you to Plack::Handler::FCGI, and to Plack in-general.

Conceptually are three ways by which the pool of server processes can be managed: static, dynamic, and external.   In the first two cases, the FastCGI processes are maintained as children of Apache.   In the third, they are required to be somewhere else and maintained by someone else, i.e. on a separate machine.   This third scenario is one of the possible very-compelling motivations for using FastCGI in the first place, vs. mod_perl or even ordinary CGI:   the FastCGI worker processes can be located on a separate machine with greater access privileges than the Apache has (running in the middle of the DMZ).   (This is the “external” scenario.)

Another consideration, which is explicitly provided-for in Plack, is “hari-kiri”:   the ability to specify that a given worker process should service so-many requests, then be terminated.   (If you are running an external farm of FastCGI workers, you will need to provide for this yourself.)   This is a pragmatic and practical way to handle un-diagnosed memory leaks, especially in recalcitrant “legacy” applications.   The terminated worker (is | must be) immediately replaced.

I like to use FastCGI technology, even on a single machine, because it clearly separates the web-server’s worker processes from those which do the heavy lifting.   The number of processes in each group can easily be different.   And, as noted previously, the FastCGI workers can be on a separate machine entirely.

I hope that this initial response gives you some things to start thinking about.   FastCGI is both a very powerful technology and a very flexible one.   And, once again, I would like to call your attention to Plack. (See plackperl.org.)   These two technologies, taken together, have enabled me to very efficiently “scale up” a number of mod_perl and traditional-CGI applications over the years.   I look forward to your response.