Re: Having problems with external servers

Mark Brown (
Tue, 17 Sep 1996 16:20:40 -0400

Message-Id: <>
Subject: Re: Having problems with external servers 
In-Reply-To: <Pine.BSI.3.94.960917075519.11833A-100000@harlie> 
Date: Tue, 17 Sep 1996 16:20:40 -0400
From: Mark Brown <>

Eric J. Schwertfeger asks:

    The question is, the server is responsible for relaunching any
    fcgi procs that die that run locally.  How can you do this if it
    isn't local?

mod_fastcgi is only responsible for processes started by AppClass;
as you note; it has no way of knowing how to restart remote processes.

If you need a process manager, the simplest thing would be to run
another Apache server on the remote machine.  You could turn off all
http access to that server, and configure it with a single child; it
really just provides a place for mod_fastcgi to live.

But you'd have to make a change to mod_fastcgi: You'd have to
generalize it, at least on the process startup side of things, to
create TCP/IP listening sockets as an alternative to the Unix
Domain sockets it uses toda  You'd add a new option to AppClass
in order to specify the port number.

The low-tech solution would be to use whatever technology
you use to keep your Web server running to keep your
FastCGI applications running, too.

    These things die entirely too easily.  Telnet to it,
    control-D, and enter, and you take the server process with you.

Use the initial environment variable FCGI_WEB_SERVER_ADDRS
to prevent this sort of attack.

For example, if your Web server uses the IP address when connecting to your FastCGI application, then

    % setenv FCGI_WEB_SERVER_ADDRS ''

before running cgi-fcgi.  Now your application will reject any 
incoming connection that does not appear to come from the Web server.
If you run with your routers configured so that the Web server's
address can't be spoofed, this is pretty good protection.