Installation of PHP+Apache: CGI vs. module

The given manual doesn’t intend to display the questions discussed completely. It doesn’t describe nuances of Apache web-server settings. Only the most necessary things are discussed. These are things connected with work of PHP together with Apache web-server. Of course, some errors and inaccuracy is possible.

I warn you at once – those who appreciate their time (or those who want to get their web-server working as fast as possible) can omit the entire introduction (and theoretical and major part of practical part as well) and cross directly to the Lesson 2. In it installation of PHP as Apache-module for Win32 is described. And as to the rest… Someone may read it… I hope, there will be a lot of readers.

Introduction

So why have I written this article? And what for I need such exotic as Apache and PHP for Win32?

For PHP-scripts checkout on a local machine I had to install web-server+PHP for Win32 (I use MS Windows on purpose as far as, from my point of view, productive work connected with web-design using Unix and its clones is simply impossible – these systems are good as server base, no more). You are not to argue with me. Besides that, you are reading this article and so you are going to install Apache+PHP namely for hated by everyone Windows.

I don’t remember at the moment which was the first web-server tested by me but starting PHP-parser by my scripts was done with string #!c:/php/php.exe which is not very convenient. But maybe… The PHP-authors (in the official documentation!) point to the fact that from the point of security this method is the best one. At this the parser itself ‘lives’ far away from files with scripts. And script is transmitted to it for accomplishment not by the web-server but by the interpreter of the command string. But I don’t think at all that there is any sense in paying attention to this method of installation.

Keeping in the mind the fact that the most providers use Apache as their web-server I decided to install its Windows-version on a local machine. And not only providers are the matter. It is one of the most configurable servers. You are left only to attach PHP. There is a plenty of manuals in the web signed by different authors but their contents were surprisingly similar… The accuracy was up to the punctuation marks. It’s obvious that such articles are clones of each other related to different periods.

So they describe the way of PHP-installation as CGI-program. This method filled up the entire net and many have no idea that it can be done in other way. But we’ll call such a method ‘alternative’. Exactly like this! Even more than this – I’m going to tell you that this method is harmful. It makes people working with Windows and Linux-fans argue. So when the first ones complain: “my PHP functions wrong” the second ones reply grinning “Windows must die! Linux forever! Install Linux and you won’t have any problems. Cause it’s IMPOSSIBLE to install PHP as Apache-module. It can’t be helped.” I’m not going to discuss advantages and drawbacks of this or another operation system. Not in this article. But I was about to join this opinion myself.

Now about impressions. We start script which is trying to send headers – no, it doesn’t function. We look up manual: what’s the matter? Oh, it’s a pity… It proves that PHP has to work as an Apache-module. But we cannot install the module for Windows… And what about authorization on code 403? It doesn’t function too… We have to reject it… Do we really have to do this? I doubt we have to! Of course, there is no universal solution that I could offer you but I’ll try to join within this article everything (or almost everything) that I know about work of Apache+PHP for Win32.

Theoretical part

So as you’ve understood (from my narration, PHP-documentation or other sources) TWO methods of PHP-installation on a web-server are possible. You may install it as a CGI-program or as a server’s mode. In general, there is no considerable difference. In any case, web-server transmits to the PHP-core the script path to which is contained within client’s browser request. In case when PHP works like CGI a new process is generated to which actually the script is transmitted. In case when module works its code already ‘ligers’ in the server’s memory. This is the principal difference. What follows from this? You are to think about it yourself.

So how to install PHP for work together with Apache web-server? Should it be installed as CGI or as Apache-module? In fact, there is no considerable difference but…As it was mentioned before you SHOULD install PHP as a module for realization of functions of work with headers and authorization. Anyway, these are occurrences of the same scale. Besides that, in case of PHP as a CGI-program variable $PHP_SELF (which should save name of the script accomplished) contains everything except for name. That is not the greatest trouble which can happen but you may need to use a script of someone else in which it is widely used… It may happen that by repeated call of script on name which is contained in the variable $PHP_SELF script simply finishes its work. A beaten link. Such a pity. Maybe it’s possible to find some other differences but it seems to me that this difference is quite enough to make your choice in favor of a PHP-module.

And one thing more. Having installed PHP as a module you’ll got a possibility to manage some of its parameters from .htaccess-files. For an experimental server it can be not so important – anyway, you are an administrator too. But distributives of some PHP-programs are delivered together with .htaccess-files which change PHP-parameters and reject their work if they cannot do this. You may correct php.ini but you’ll have to do it for each script… No, it’s impossible!

So the short theoretical part and long introduction which looks more like lyrical digression are over. We start our practice.

Practical part

First of all I recommend you to check work of Apache web-server UP TO some humiliation. Believe me, this will save you and others a lot of time, nerves and physical power. Don’t install PHP without checking working ability of Apache. Even if you want it VERY MUCH. Everything should be done in time. It will be much easier for you to localize the reason if you won’t hurry.

Lesson 1. Installation of PHP as CGI

The question given is rather well discussed in the Net. But we are also going to mention it briefly focusing our attention on the midpoints.

Here is an alternative method. First of all it is recommended to put everything which is connected with the local copy of web-server into one directory; and after that you should link up directory as a virtual disk with command subst f: path-to-the-directory to make everything ‘like in Unix’. It is really a wise solution. It is especially convenient not to climb over the directories’ trees (cause we are not monkeys, anyway) but have everything related to web-server available. But not all of us have a possibility to mark out the whole logical disk for experiments. And so the given advice is rather useful.

I’m not going to pay much attention to installation of a web-server itself. There is nothing difficult; all the configurative files are self-documented rather well. And there is A PLENTY of manuals about its installation and setting in the Net.

And so Apache is already installed into directory like f:/usr/local/apache (‘f’ is the letter corresponding to the virtual disk) and is completely capable of working. Correspondingly, it would be good to install PHP nearby – for example, into f:/usr/local/php

We unpack archives of the PHP-distributive. Not so many files are vitally important for us.

These are:

• php.exe — interpreter of the command string
• php4ts.dll — the PHP-core itself
• php.ini-dist — configurative file, version from distributive

Imagine, that’s ALL! Someone may ask: why the original distributive takes 3-5 megabytes in the archives (it depends on version and integration). I happens because it contains different extensions libraries for image generation ‘at one jump’, for working with databases Postgre SQL, SyBase SQL and so on. You are to mention: MySQL-support in PHP version 4 is integrated directly into the core and doesn’t need any optional files. You may add all these extensions in any moment.

So you’ve copied php.ini-dist from distributive into Windows-directory and changed its name to php.ini. You’ve tested if PHP works on its own. Create a text file with name, for instance, test.php: <? echo "TEST" ?> within the directory with PHP.

And you start it from the command string: php.exe test.php

You’ll get following:

Content-type: text/html TEST

This means that PHP works on its own.

If you haven’t got either Apache or PHP function you shouldn’t start configuration of the sheaf Apache+PHP. Let them work separately first. Move to the unit ‘Troubleshooting’.

So the preceding step showed us that everything’s all right.

Following settings concern only the Apache configuration file httpd.conf. We add mime-type corresponding to the extension of PHP-programs: AddType application/x-httpd-php .php .php3 .phtml

At that it should be done in the section of description of mod_mime module – this is a standard Apache-module. Or you can add into configuration file mime.types – but it seems to me to be better to do some changes within one file only instead of doing this within ten files at once.

Then we’ll put action into correspondence with the type indicated by us:

<Directory "f:/usr/local/php">
  Options ExecCGI
</Directory>
ScriptAlias "/__php_dir__/" "f:/usr/local/php/"
Action application/x-httpd-php "/__php_dir__/php.exe"


This is recommended to do immediately before Virtual Hosts section.

We’ve copied the text file created by us into the root catalogue of web-server and entered its URL in the web-browser string. It should function properly. If it doesn’t – move to the section ‘Troubleshooting’ below. It may help. Also you are to look up Apache settings – especially section Virtual Hosts in case you’ve tried to address your server by name (something like http://johnsmith.com/test.php).

Lesson 2. Installation of PHP as an Apache-module

The necessary materials (minimum with which everything functions):

• php4ts.dll (the PHP-core itself)
• php4apache.dll (module for Apache)
• php.ini (it is clear)
• php.exe (everything works perfectly without it but this may be useful for checking of PHP-core efficiency)

Progress of work

• We copy php.ini into the Windows-directory (its placement may be different but mostly it is on c:\windows)
• We create a directory into which we are going to put php4ts.dll and php4apache.dll. According to the agreement mentioned above - f:/usr/local/php
• We find section httpd.conf "Dynamic Shared Object (DSO) Support" – it is very easy to find and contains a plenty of (usually documented) strings of the LoadModule type… And add a string of our own:

LoadModule php4_module "way to directory-php/php4apache.dll"

If you followed the recommendations for naming of directories mentioned above it would look like following:

LoadModule php4_module "f:/usr/local/php/php4apache.dll"

We add mime-type AddType application/x-httpd-php .phtml .php .php3 .php4. If you’ve used an alternative method before (installation of PHP as CGI) it’s time to remove strings connected with comparison of action for the indicated type – we simply surpass it with comments:

#<Directory "f:/usr/local/php">
#  Options ExecCGI
#</Directory>
#ScriptAlias "/__php_dir__/" "f:/usr/local/php/"
#Action application/x-httpd-php "/__php_dir__/php.exe"
That’s all – let’s try to start Apache. By normal work you’ll see a string like that: Apache/1.3.12 (Win32) PHP/4.0.4pl1 running... 


Troubleshooting

Suppose you haven’t got it working at the first time... What should you do? First of all you are to send a message like “Help! Nothing functions!!!” to all the conferences. The main task is to submit as little information about your system as possible – it’s all right because only prodigies and telepaths take part in conferences. Such people have no trouble in guessing what system you are working with and what the matter could be. By the way postings typed with capital letters are answered in the conferences fast of all. Cause eyes get spoiled because of durable computer usage and your posting typed with lower-case letters can be left without attention…

And speaking seriously, there shouldn’t be any panic. Let’s examine the situation step-by-step.

Symptoms: Apache got started but scripts aren’t accomplished – they either get into the browser window or intend to be saved on the local disk.

Diagnosis: Script isn’t transmitted for accomplishment to the PHP-parser.

Treatment:

1. Check working ability of PHP itself. For this you are to create a file, for instance, test.php within directory with php.exe:

<? echo "TEST" ?> 

Start it with command php.exe test.php. You should see following:

Content-type: text/html TEST

Notice: there is a blank string between 1st and 3rd strings. It’s all right. There can be nothing else.

If it doesn’t work, you are to check if you’ve got all the necessary files. You need file php4ts.dll either in the directory with PHP or in the directory which is contained within PATH network variable. Throw it into the system directory of Windows and forget your troubles. (I’ve warned you – check working ability of the components first!)

What should you do if problem persists? You should look a bit deeper… File php.ini included into distributive demands setting up only in the special cases. Believe me your case is quite ordinary. Probably the matter is damaged accomplished files of distributive.

2. PHP functions on its own… Let’s check connection Apache+PHP…

If your PHP is configured for work as Apache-module (I recommend you to set it up like this), you are to check loading of the module and appointment of mime-type application/x-httpd-php

If PHP works as an external program you are to check appointment of action which is brought in correspondence to the type given (see Lesson 1) along with mime-type.

Symptoms: Apache cannot be started at all. Black window of MS-DOS session appears and is shut at once.

Preliminary diagnosis: Invalid Apache configuration. Something is wrong within configuring files. Either the library necessary for PHP-module starting (php4apache.dll) or the core itself (php4ts.dll) is absent.

Treatment: make diagnosis more precise:

• Open a new MS-DOS session window (you may also use Norton Commander, DOS Navigator and so on)
• Start Apache (attention!) from the command string: apache.exe
• And now look what it says…

If you cannot mange to find out the matter on your own it will help a lot a specialist who you would ask for help. Descriptions like “I’ve installed everything properly but it doesn’t function nevertheless” cannot satisfy anyone. However Apache informs us why it cannot start although it does it rather obscurely (is anything else possible in the program world?) So my advice is: LOOK AT THE SCREEN – it often informs you about what causes program errors. Not always but often. And the given case isn’t an exception.

So you are to try to remember if it has said something like this BEFORE installation of PHP. If not then:

In case of installation as CGI check correct writing of Apache settings directives and the sections in which you’ve made changes. There are no other variants. The matter is this and nothing else. Cause PHP is called Apache for scripts accomplishment and doesn’t perform any role in starting Apache itself. And so we are going to discuss PHP as Apache-module ONLY. We are not going to examine CGI any more.

If you install PHP as Apache-module you are to check it lacks something. Try, for instance, to put php4ts.dll in the directory with Apache. Sometimes it helps. So you may give vent to your fantasy. Not to your hands! You are not to punish your computer for your clumsiness. Anyway, it looks a bit scaring – Apache is breaking down causing error in apachecore.dll. This all isn’t true. You need some beer fro your work and programs need libraries and configuration files for theirs, don’t they?

According to my observations different Apache-versions behave a bit differently by connection of PHP-module. Please correct me if you have any reasons for other opinion.

So Apache 1.3.12 firstly searches for php4ts.dll in its own directory (where Apache.exe is placed) and then within directories indicated in the PATH network variable. It’s quite possible that in your case php4ts.dll form another PHP-version is placed in the Windows system directory. As a rule the old version is used. And php4apache.dll cannot download it. And it simply doesn’t find THAT VERY version. Frankly speaking, I can’t stand when programs throw their libraries into system directory by installation. I’d rather put up with the fact that the same library will be placed in two directories. I’m talking about directory of Apache and about directory with php.exe (sometimes useful) and library php4apache.dll. Generally speaking, this all can be placed directly in the Apache-directory – you don’t need to go far and making update is much easier – you won’t forget your old library anywhere.

Apache 1.3.14 firstly searches php4ts.dll in the directory where php3apache.dll is placed. In this case you may put all PHP-files into one directory. I’ve done this.

There are some cases when you try to attach to PHP-module of Apache optional modules and libraries from other PHP-versions (for example, the notorious php_gd.dll). I’m not sure you manage this. Anyway, Apache (namely PHP included in it) curses when internal API-versions don’t coincide. You’d better switch off them all first. It’s clear where you should do it – in php.ini. Anyway you are to examine messages shown up by starting carefully. And one more thing. Connecting optional modules you are to record variable extension_dir into the file php.ini – on default PHP searches them in the same directory where (./) is placed; and in the distributive they lie in the directory extensions/ - isn’t it strange?