Further, if you're using apache 2 as your front end reverse proxy, you'll be fine running it as your backend static web server as well (in a different configuration); it's another instance, not a whole different app type to monitor. If your monitoring framework can do it in the first layer, it can do it in the second as well.
The niche for static serving out of the fastcgi process would be where you want more security than one single web server, but you aren't into huge scaling issues where dynamic and static content will be managed separately. I'm not really convinced it's a big niche, though - if you aren't into huge scaling issues, you can just put a reverse proxy on the front of your existing web server to get close to the same effect (since security vulnerabilities in the second layer that are still exposed through the proxy are liable to be app errors rather than server bugs, so no amount of separation short of an HTTP-speaking proxy or filter is going to guard against this - at which point we're into a whole different territory of architecture). I agree with the general tone on this thread - while a better fastcgi implementation is great, it doesn't need to serve static files. I wouldn't use it for that. James -- James Aylett Chief Technical Architect t 020 7535 9850 f 020 7535 9900 w http://tangozebra.com/ Tangozebra may not be held responsible for the content of this email as it may reflect the personal view of the sender and not that of the company. Should you receive this email in error, please notify the sender immediately and do not disclose copy or distribute it. Tangozebra runs anti-virus software on all servers and workstations, and cannot be held responsible for any infected files that you may receive. Tangozebra advises all recipients to virus scan all emails, and to eat five portions of fruit and vegetable daily. -----Original Message----- From: Andi Gutmans <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>; internals@lists.php.net <internals@lists.php.net> Sent: Mon Nov 27 05:40:15 2006 Subject: RE: [PHP-DEV] Re: [EMAIL PROTECTED] RE: [PHP-DEV] new apache fastcgi implementation and phpfastcgi patch I understand the thinking behind this but I still don't understand why PHP should serve static files. You can still forward static content to the machine running PHP but to a different port as an HTTP request. You can have any Web server of your choice on that machine serving static files, and it can even serve it from the same application layout structure so that application deployment is not an issue... Andi > -----Original Message----- > From: Mathieu CARBONNEAUX [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 26, 2006 3:46 PM > To: internals@lists.php.net > Subject: [PHP-DEV] Re: [EMAIL PROTECTED] RE: [PHP-DEV] new > apache fastcgi implementation and phpfastcgi patch > > 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:[EMAIL PROTECTED] > To: [EMAIL PROTECTED], internals@lists.php.net > Sent: Sun, 26 Nov 2006 18:38:39 +0100 > Subject: [EMAIL PROTECTED] 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 > > > > -----Original Message----- > > From: Mathieu CARBONNEAUX [mailto:[EMAIL PROTECTED] > > Sent: Sunday, November 26, 2006 2:59 AM > > To: internals@lists.php.net > > Subject: [PHP-DEV] new apache fastcgi implementation and > php fastcgi > > patch > > > > hi every body, > > > > i've developped a new implementation of fastcgi module for apache. > > i'have used the scheme handler of mod_proxy of apache like new > > mod_proxy_ajp in apache 2.2... > > the idea is to make possible proxyfy php application behind apache > > (for security et and performance...). > > to make possible to execute fastcgi in one machine and > apache in other > > machine... separed by firwalle (two DMZ)... > > > > the developpement of the old module as been stoped... > > > > is why i've decide to reimplemente all in new code with decente > > licence (apache 2 licence...for the moment...) > > > > but in this way php receve all request: image, binary file, static > > file...and also php file... > > for the php file no probleme... but for binary and image... > > they try to interpret systematicly... > > > > to evitate this i've modify the fastcgi sapi to handle this in the > > good way... > > they only execute by the php interpreter file with a list > of extension > > (.php .php4 .php5...) all other file are served directly... > > i've also modify the sapi to handle index file (index.html > > index.php...)... > > > > i have some dev to add new parametterer in php.ini to handle this > > addition... > > but after how i can add to php trunck my dev ? > > > > they modify only php cgi/fastcgi sapi ! > > > > my code are her: http://mproxyfcgi.sourceforge.net/ > > > > Best Regards, > > Mathieu > > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
