The problem is not that Apache rewrite rules in the .htaccess
file won't work when running PHP as a CGI vs. an Apache module. It's just you can't use the .htacess
file to set PHP values when it's ran as a CGI. Instead you have to have a separate php.ini file that has your settings changed in it. Within my own shared hosting account, which runs PHP as a CGI, I make use of FastCGI and have the following in my .htaccess
file:
<IfModule !mod_php.so>
AddHandler myphp-script .php
Action myphp-script /cgi-bin/myphp.fcgi
</IfModule>
Then in my accounts /cgi-bin/
directory I place the myphp.fcgi
script with chmod 755
containing:
#!/bin/sh
# This ensures PHP doesn't try to run it's own
# process manager.
export PHP_FCGI_CHILDREN=0
# Execute PHP with my php.ini config file
exec /path/to/system/cgi-bin/php -c ~/myconf/php.ini
I still have a <IfModule mod_rewrite.c>
section in my .htaccess
file to handle rewriting some old URI paths to the new URI structure to maintain old links that are cached in search engines.
Using suexec and suphp enforce a different type of privilege separation than the default.
The default is to separate the user's permission from the web server. That is, the user owns the files, and he has to grant the web server permission to view and change them.
The suexec/suphp model is that the webserver (when running scripts) runs under the user's account, so the website has permission to do anything that the user has permission to do. To a certain degree, this removes the separation between the user and the webserver, but in exchange it enforces a DIFFERENT separation: that is, between the website of one user and the website of a different user on the same box.
By default, PHP always runs under Apache's user account, so one website's PHP scripts can access any files that another site's PHP scripts can. Therefore, if one account on the server gets hacked, the infection can spread to the others. SuPHP prevents this.
Neither suexec nor suphp will affect the way apache serves static content. All the old rules still apply. Instead, suexec and suphp change the account under which CGI and PHP (respectively) will run. Suexec makes CGI executable run under the owner's account, while SuPHP makes PHP scripts run under the owner's account.
Suexec and SuPHP aren't necessarily better. They're just different. They won't prevent a website from being hacked (and arguably might make the site easier to hack), but they will prevent a compromise on one site from spreading to all the others. To the site administrator, this isolation is arguably more important, which is why some shared hosting systems make suexec and suphp the default.
One extremely common "gotcha" is that SuPHP checks the ownership and permissions of a script before it runs, and will return a 500 error if the permissions aren't appropriate.
In particular:
- The owner and group of the file must match the website owner (as setting in apache configuration)
- The file must not be world-writable
- The parent directory must not be world-writable
Best Answer
Those are not really "6 PHP Types", rather two PHP types, each running in 3 different Apache implementations.
suphp, suphp_worker and suphp_event
suPHP itself is a wrapper for PHP, running PHP under given user rights (eg differing from the rights Apache runs under) plus an Apache module (mod_suphp) which allows you to run suPHP - basically in a CGI mode. CGI mode simplified means, that each request passed through to PHP starts a new PHP (runtime) process. This is expensive, in terms of CPU usage, and slower compared to a persistent PHP runtime (~about 3-5 times, i'd guess).
I assume this first variant uses the Apache's prefork MPM, which is widely used and tested but rather slow, compared to other MPMs. Prefork does what it name implies: It forks a given amount of apache processes and holds them available for incoming requests.
The next (suphp_worker) uses the worker MPM instead. Worker is a mix of pre-spawned processes and threads, which is generally faster than prefork (for delivering static contents about twice) and uses less memory.
The last (suphp_event) seems to use suPHP + MPM event, which uses yet again another process/thread model than worker. From benchmarks i've seen, event and worker are about the same speed - the event MPM (at least using Apache 2.2, which your provider probably does) is marked as experimental.
mod_php, mod_php_ruid2 and mod_php_itk
This is a differnt kind of PHP handler implementation: Apache pre-starts a PHP runtime and passes incoming requests to it, spawning new processes as needed. This is considerable faster than suPHP but comes with the downside of having no user right separation: all the php processes run under the same rights as Apache itself.
The first variant probably uses the prefork MPM (described above) as mod_php is incompatible with the thread models from worker or event.
The second variant (mod_php_ruid2) seems to use the Apache module mod_ruid2 in addition, which allows you to run each Apache VirtualHost under differnt user rights - this includes PHP processes. It has a long list of incompabilities which you should consider.
The last variant (mod_php_itk) uses the third party ITK MPM for Apache, a fork of the Apache prefork MPM with the option run each VirtualHost under given user rights. It also gives you the ability to enforce additional limits (eg amount of clients) per VirtualHost.
Suggestion
If those are your only choice, and you are "alone" on your Machine (aka: you do not plan shared hosting) i would probably stick with good ol' mod_php.
If you are planing multiple websites you need to check with your priorities:
I do prefer using a third option, which uses FastCGI, giving you even more possibilities to separate rights and access priviliges - but this seems not to be offered.