On 11/11/2010 02:14 PM, Didier Gasser-Morlay wrote:
On 11/11/2010 12:04 PM, Richard Quadling wrote:
On 11 November 2010 00:46, Al<n...@ridersite.org>  wrote:
Briefly, what are the trade offs on a typical shared host?

I've done a little research and can't seem to find anything outstanding
either way.

Seems like as an Apache module is faster. This argument makes sense.

CGI is more secure, this argument doesn't seem too persuasive to me. Maybe
I'm missing something.


As a module, any misbehaving script is running within the same space
as all the other scripts. If a script is able to knock out PHP (for
any reason), all the script go.

With CGI, they are run in separate spaces. No direct communication
(unless the scripts are sharing memory by some way). If a script
knocks out PHP, that script dies. Everything else keeps on going.

The main downside to CGI (as I understand things), is that for each
invocation of the script, PHP has to do the complete build up and tear
down every single time. For every single script.

With FastCGI, when the server starts, a pool of ready to go php
instances are created. So a script is called, the build up part is
already done.

In terms of speed, I'd guess you'd have to be working pretty hard to
see the difference between module/isapi and fast-cgi.

If I am not mistaken, An apache module can even bring down the whole web server if it really misbehaves.

So this leaves the choice between CGI & FatsCGI.

CGI setup/teardown is only an issue for site with a fairly high traffic. It really depends on the type of site you intend to build.

To me, the main security issue with mod_php in a virtual domain configuration is that it runs as the apache user and therefore any php code can read any files accessible to apache. If you have clients maintaining their own php code, they can access the code (and passwords and databases) of your other clients.

I've never used cgi but I hope that it allows you to avoid this problem. Am I correct?


PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to