hi,
the reverse proxy way (is complet different way than old apache fastcgi that is apache handler like mod_php) of apache is only proxy that redirect all request to there backend with new connection (some time with different protocole than front protocole, ex: https to http, http to ajp...).
the idea of the reverse proxy mode is to deport execution logic on different machine than the machine who own apache reverse proxy...
and with deported execution logic, the advantage to handle static content in php sapi is to deport completly the deployment of static content out of the apache reverse proxy dmz ...
and in that way when you deploy new php application, you deploy all file in only one place...
and with apache 2+ you can use cache module to cache all static content in reverse proxy stage, in that way php fastcgi don't have to make mutch work...
and the idea is to not add another processus to supervise (is exploitation in mind) and other technology like other http server (another competence than "apache" to add to team who supervise)...
the apache fastcgi (www.fastcgi.com) is developped with licence who make dificille to realy make possible to modify the source in comunity...
some patch exist only in php bug track to correct bug but they and actualy not apply in apache fastcgi trunk...
the apache fastcgi project are quasi frozen...the last update are from 14 April 2004...
is why i've developped this implementation...
Actualy i've only implemented the handler modele of fastcgi protocole spécification...
the seconde stage is to implement authentification modele...
and the 3rds stage is to implement filter modele...
and othe idea for the futur....
i'have implemented this module in base of the idea of the reverse proxy implementation of AJP protocole (tomcat protocole is very similare to FastCGI protocole...)used in apache 2.2.
and is the idea of all proxy/plugin module in java environement like mod_jk, proxy ajp, websphere, weblogic ....
the idea is to separate the exposition to the web to the execution of web application in two different zone (DMZ).
in that way you can add mod_security like (for exemple) module, and with mod_cache (to cache static file) module with the reverse proxy module (proxy ajp or fastcgi, mod_jk, was/wls plugin...) in the first dmz...and the application in the seconde DMZ (php, tomcat, ...)...
some personne have developped similare module for apache 2.3 dev version...
and i know it for only short time, in fact i've developped my module in paralelle without knowing the existence of the other project... but my module is developped for apache 2.0+...
and i've seen the same probleme with other file than php script in apache 2.3 version...etc...
i'm ok with you about contributing to apache, but i've sended mail in the mailing list to contact developper but have no return... i go to reitere my mail to the list...
but my module can be out of the box of apache trunk beceause is standard apache module and can be added out of the box to apache.
but the modification in server fastcgi in scripting language is embeded to the language... and i've developped the php fastcgi sapi modification to make possible to use this version of fastcgi implementation with php...
without this modification the reverse proxy fastcgi implementation don't work correctly...
is why a whant to add my contribution to php sapi fastcgi, in that way i'm not oblige to maintaine patch to php sapi...
and my modification don't modify cgi implementation and are completly compatible with the old fastcgi implementation...
Best Regards,
Mathieu
_____
From: Andi Gutmans [mailto:andi@zend.com]
To: info@ch2o.info, internals@lists.php.net
Sent: Sun, 26 Nov 2006 18:38:39 +0100
Subject: [info@ch2o.info] RE: [PHP-DEV] new apache fastcgi implementation and php fastcgi patch
Making the PHP SAPI extension know how to handle static files does not sound
like the right solution to me. You should be able to redirect the PHP
requests only to PHP's FastCGI (which already works today incl. remotely),
and redirect the static content to a Web Server (thttpd or something alike).
I personally don't see a great reason adding such a patch to PHP itself.
Btw, what are the advantages between your and Apache's FastCGI
implementation? This is something you might want to share with the Apache
httpd folks because if it's a good implementation then it might be nice to
contribute it to them.
Andi
