Well, after another strong cup of coffee (and a long, hard look at something stronger ... but it’s too early in the morning here ...), I did figure it out.   For those who will surely come after, let me summarize my headaches here.

(1) There are three ways that a script can be deployed into FastCGI land, including “dynamic,” which allows a CGI-style script to be deployed with virtually little change, but I knew that I didn’t want to have to fool around with mod_rewrite and /cgi-bin and all that nonsense.   The appropriate way to do this was to use the FastCgiServer directive, (necessarily...) outside of any <VirtualHost> container, so that Apache would start that process under its FastCGI process-manager at startup time and try to keep it running.

• “Dynamic” mode is not what is wanted here, because we are not trying to “run CGI scripts but in FastCGI mode” here, which is what this fee-chur is designed to do.   But mod_fastcgi will try to launch, well, anything at all, as a process if you let it.   (“Just tryin’ to help, that’s all...”   Yeah, I know, and “thanks, but...”)

(2) The voodoo to get requests to go to the right place is something like this, as the last entry:

  <Alias    / "/pathname_of_fastcgi_ending_with_slash/"
  <Location />
     <Allow from all>
     # Do NOT put "SetHandler fastcgi-script" here!!
  </Location>
[download]

The headaches here are:

• You need that trailing slash.
• If you do include Set/AddHandler, Apache will think that you are trying to use dynamic servers, in addition to the ones that you specify, and it will try to execute any file that you try to serve.   You’ll see (dynamic) and probably is a directory! messages in your logs.

(3) My application is using Plack::Handler::FCGI as the guts of “the FastCGI server,&rdqo; and Plack::Util::load_psgi to load the app.psgi file (which allows the easy use of plackup for offline testing.   I found out the hard way that this must not use the daemonize (detach...) options, and that if you do this, you’ll get a flood of worker-processes reminiscent of The Sorcerer’s Apprentice!   (The process launches its kids and then dies, and Apache notices that “the static server” has died and so re-launches it...)

• Apache can launch n static servers and keep an eye on them.   The Plack handler aforementioned is also capable of the same trick.   You’ll probably want to do it one way or the other.

(4) Attempts to use Plack::App::WrapApacheReq were not successful, but not for “it didn’t work” because, in fact, it worked splendidly ... but in the end I wound up “cabbaging” it, instead, because as-written it was not quite what this crufty old application demanded..   This site and the associated Git repository were a life-saver too.   I switched some of the code based on PlebGUI’s “Plack session” object to eliminate uses of old crufty mod_perl things (like APR...), and simply changed the code in some parts of the application to make it vaguely reasonable.   (The final guts of app.psgi are basically lifted straight from PlebGUI’s code repository.)

(5) One of the changes that I had to make was to remove the code that “redirects to https:” for certain functions, if plackup is being used.   For obvious reasons, plackup can’t do SSL.   Therefore, that part of the (application’s) code is now wrapped-up in this:

unless (defined($ENV{'PLACK_ENV'}) && ($ENV{'PLACK_ENV'} =~ /developme
+nt/i)) { ...
[download]

... so that the application does not specify a redirect to SSL when it sees that it is running under plackup.

(6) All of the rest of the stuff is simply a by-product of the fact that FastCGI runs everything in an external process.   The legacy application used a lot of very mod_perl-specific directives, direct calls to libapreq2 and many other disgusting things.   I am fortunate that those changes were concentrated in only a couple of targeted places within the code.   (It was, for its day, is “a well-designed, albeit very mod_perl-loving, application.”)

If, going forward, I can help the next Monk avoid some of the lumps that I have just taken, I will be more than happy to help.   (And, P.S., everything they say about “PSGI is faster” has turned out to be my experience with this application as well.)