Re: FCGI and FilterData
Fri, 17 May 1996 09:50:32 -0400 (EDT)

Date: Fri, 17 May 1996 09:50:32 -0400 (EDT)
Subject: Re: FCGI and FilterData 
To: Mark Brown <>
In-Reply-To: <>
Message-Id: <ML-2.3.832341032.7419.rasmus@rathaus>

> What Filter allows you to do is to write URLs that refer directly to
> the script in question, not indirectly by naming the PHP/FI interpreter
> and then naming the script in the "virtual path".  The most significant
> benefit of this arrangement is that the Web server becomes responsible for
> performing access control to the script, rather than placing
> the PHP/FI interpreter in the role of performing access control.
> A secondary benefit is that users just need to put the correct extension
> on the script name, rather than having to insert the path to the
> interpreter.

I already do this by simply doing a CGI redirection at the server-level.

ie. for Apache:

  AddType application/x-httpd-fcgi .fcgi
  AppClass /usr/local/etc/httpd/fcgi-bin/php.fcgi -processes 4
  AddType application/x-httpd-fphp .fhtml
  Action application/x-httpd-fphp /fcgi-bin/php.fcgi

This means that any .fhtml file will automatically get handed off to be
parsed by one of the 4 running php.fcgi parsers.  Access control is done
by the server, and users do not need to have php.fcgi in the URL.

I have written an NSAPI module for NetScape servers that does CGI
redirection similar to the Apache mod_action module illustrated above.
And I have also written a patch for NCSA 1.5 which does the same for that
server.  (These are available at:

However, I can see how this is a useful thing for servers that are not
able to redirect specific mime types to a given CGI.