Php: CGI and Module

Anon

Hi everybody:

What is the difference of using php as cgi or as a module ??

I am using php in my server, but how can i now that php is installed as cgi or as a module ?

      Thanks for your help, nice coding:


          Mariano Burgos.

Anon

Hi Mariano

Having built many servers running PHP now, the difference is purely speed and security, as a CGI the PHP core can make your server vulnerable to attack (at least that's what we found) and the server also has to spawn a separate process for each document called per virtual server.

As a module, Apache has the PHP core code built in (or loads it dynamically dependant on how you compile it), this makes your scripts execute a lot faster.

The way that I have found (in my opinion) to distinguish is by the inclusion or ommision of the "--with-apache=...." command during the configure process, if you leave it out, you get PHP built as a CGI, if you put it in and then recompile Apache afterwards, it becomes part of the core.

If you have the chance, compile it twice, first as an apache module and then as a CGI, this sounds like a waste of time - BUT, make Apache use it as a module and keep the CGI binary tucked out of the way on the server. If you write a site that requires some off-line processing (eg via cron), instead of writing a PHP version for the web end and a PERL version (and have to compile MySQL modules and such like into the Perl core) for the back end processing.

You can have one code library which can be called either side of the interface.

For example, you have a large code library that handles data structures in a table.

All you have to do is use the include() function in your code for both scripts and use the same function twice rather than re-writing it - saved us a lot of time for one of our web-based management systems.

Hope this helps.

Anon

CGI modules read parameter files every time they execute. Modules do it once when the server starts up. This is the same for many Apache applications.

For test servers, you want to start with CGI so people can experiment and learn. Let them change settings like the PHP include path.

For quality assurance and acceptance testing, you want those parameters documented and locked down.

For your own production servers, you want the setup paramenters locked down. You also want to save the overhead of reading the parameter file many times. Use the module version.

If your production server hosts other sites, you may want to have some applications running as CGI instead of modules so each customer can use their own parameter file. The hosting service I use, has options to use a variety of scripting languages and databases. I am using PHP4 while other clients are still on PHP3. I can use my own php.ini file because they let me use PHP as CGI. They have unusual security relying on some features of Solaris. I would not try CGI with user built .ini files unless you happen to know everything about security and also can see several months in to the future so you can fix security problems before the problems are discovered.

Speed:
By the time you write long CPU chewing scripts, you will be using databases. On production systems with big databases, the databases are always slower than the scripts. Operating systems, like NT and Linux, can cache a .ini file if there is heaps of memory.

If there is not enough memory, everything will slow down. The module version of most products will use less memory.

Think
Initial testing: CGI
Production: Module

Anon

You can determine which method is being used on the server by making a PHP file with the following line

<?php phpinfo(); ?>

It will then display the detailed PHP environment. At the top of that page you will see info such as the build date, compile switches, and a Server API. If it is being used as CGI you will see CGI, if it is a module you will see Apache.

There are lots of other goodies on that page as well, so have a look. I don't think there are any security restrictions denying the use of that function, so you should be good.

Tim Frank