Re: FCGI and FilterData

rasmus@madhaus.utcs.utoronto.ca
Fri, 17 May 1996 09:50:32 -0400 (EDT)

From: rasmus@madhaus.utcs.utoronto.ca
Date: Fri, 17 May 1996 09:50:32 -0400 (EDT)
Subject: Re: FCGI and FilterData 
To: Mark Brown <mbrown@OpenMarket.com>
In-Reply-To: <199605171339.JAA03834@breckenridge.openmarket.com>
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: http://www.vex.net/php/files)

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.

-Rasmus