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 andi@zend.com
To: info@ch2o.info info@ch2o.info; internals@lists.php.net internals@lists.php.net
Sent: Mon Nov 27 05:40:15 2006
Subject: RE: [PHP-DEV] Re: [info@ch2o.info] 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:info@ch2o.info]
Sent: Sunday, November 26, 2006 3:46 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Re: [info@ch2o.info] RE: [PHP-DEV] new
apache fastcgi implementation and phpfastcgi patchhi,
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 patchMaking 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:info@ch2o.info]
Sent: Sunday, November 26, 2006 2:59 AM
To: internals@lists.php.net
Subject: [PHP-DEV] new apache fastcgi implementation and
php fastcgi
patchhi 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
--
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
Why php cannot be able to be a real application server!? :)
no, no, no i've not said that... :) ok...
no really, separating static from dynamic serving are not in the logic of reverse proxy apache "scheme" handler implementation who serve by default all file from path to a backend...
my solution work like ProxyPass apache proxy command:
ProxyPass / fcgi://my.fscgi.server.com/
if you whant another implementation of apache fastcgi implementation like the old one who serve only file extension is not the way i've choose...sorry...
I’ve made apache proxy "scheme" handler (like proxy module "ftp" or "ajp") and is not apache "handler" or "filter" like mod_php or mod_fastcgi(the original one).
this is a method to make apache module for the apache proxy infrastructure, and make possible to implement "scheme" handler hook that implement protocol handler like "http:" or "ftp:". is the way I’ve used to implement the protocol "scheme" "fcgi:".
but with my code base I can be able make "handler" module like the original one without too much work...
but i go to do that after I’ve resolve my need...the reverse proxy mode !
and if you have 100 or 200 php instances (and the same number of reverse proxy in front) to manage...
and if you add one apache to each fastcgi server all multiply by 100-200 ...
is more complicate to manage and consume more memory(apache processus+php fastcgi processus*100-200)...
if i can suppress apache (or equivalent) in the equation of the php side i'm happy...more memory free to php fastcgi...
and if i use apache in parallel to php fastcgi why not use directly apache + mod_php (and always the reverse proxy in front)
and with apache + mod_php this solution consume less memory on php side than apache + fastcgi/php...
and is more simple to configure than making apache (or other http solution) for static and php fastcgi for dynamics...
my need is to make complete separation between apache and php.
And making php a complete application server...like AJP implementation vs tomcat/jboss like...
to make an only one architecture type with mixed application language... (php, tomcat, weblogic, websphere...)
and separating static file vs using cache on reverse proxy for caching static content... in performance i thing is similar...
and if is similar with separate it if is more simple manipulate...and administrate...
but why why....
Best Regards,
Mathieu _____
From: James Aylett [mailto:james.aylett@tangozebra.com]
To: andi@zend.com, info@ch2o.info, internals@lists.php.net
Sent: Mon, 27 Nov 2006 08:35:05 +0100
Subject: Re: [PHP-DEV] Re: [info@ch2o.info] RE: [PHP-DEV] new apache fastcgi implementation and phpfastcgi patch
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 andi@zend.com
To: info@ch2o.info info@ch2o.info; internals@lists.php.net internals@lists.php.net
Sent: Mon Nov 27 05:40:15 2006
Subject: RE: [PHP-DEV] Re: [info@ch2o.info] 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:info@ch2o.info]
Sent: Sunday, November 26, 2006 3:46 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Re: [info@ch2o.info] RE: [PHP-DEV] new
apache fastcgi implementation and phpfastcgi patchhi,
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 patchMaking 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:info@ch2o.info]
Sent: Sunday, November 26, 2006 2:59 AM
To: internals@lists.php.net
Subject: [PHP-DEV] new apache fastcgi implementation and
php fastcgi
patchhi 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
--
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