views:

66

answers:

4

Hi,

I've almost finished writing a HTTP/1.0 compliant web server under Java (no commercial usage as such, this is just for fun) and basically I want to include PHP support. I realize that this is no easy task at all, but I think it'll be a nice accomplishment.

So I want to know how PHP exactly interfaces with the Apache web server (or any other web server really), so I can learn from it and write my own PHP wrapper. It doesn't necessarily have to be mod_php, I don't mind writing a FastCGI wrapper - which to my knowledge is capable of running PHP as well.

I would've thought that all that PHP needs is the output that goes to client (so it can interpret the PHP parts), the full HTTP request from client (so it can extract POST variables and such) and the client's host name. And then you simply take the parsed PHP code and write that to the output stream. There will probably be more things, but in essence that's how I would have thought it works.

From what I've gathered so far, apache2handler provides an API which PHP makes use of to 'connect' to Apache. I guess it's an idea to look at the source code for apache2handler and php5apache2.dll or so, but before I do that I thought I'd ask SO first.

If anyone has more information, experience, or some sort of specification that is relevant to this then please let me know.

Thanks in advance!

A: 

To put it simply, this is how it works:

Apache normally serves files by fetching the file and sending the stream down the HTTP connection. With PHP, however, Apache fetches the file, pipes it into the PHP binary, and sends the output stream from the command down the HTTP connection.

Delan Azabani
This is a good start, but the interface is more complex than that. Don't forget PHP has abilities like modifying the HTTP headers before Apache sends off the content ..
Matt
This is exactly what I had in mind at a very simple level, but I agree with Matt. PHP does more than that. Right now I've got a Parser class which can parse client output and headers just the moment before its sent off (at the moment it simply returns the output and headers with no modification). And ideally I want to integrate PHP at this point.
Sbm007
+1  A: 

In addition to the php file, HTTP request, and the client host name, there are certain other items of information typically passed to PHP to set certain other elements of the $_SERVER superglobal. The linked documentation page has a list of what is typically set.

Amber
Yup, I'm aware of that in fact it's probably all the info that's under the 'Apache Environment' section of phpinfo().
Sbm007
Hmm, I just realized $_SERVER has got a argv and argc variable which contains the arguments passed to the interpreter. I think I'll run a simple PHP script and output the argv and argc contents, this will probably give me a better idea of how PHP is invoked. Scrap that - blank output - Apache does not externally contact php.exe, there must be more going on internally than just querying php.exe.
Sbm007
+1  A: 

The key word is CGI.
It is dramatically simple protocol, which serving web-servers for ages.
It is not the only way for PHP to interact with a web-server, but most common and easy to implement one.

In short, your server must set up some environment variables, and then call a cgi-script which is just a php script itself.

Col. Shrapnel
+3  A: 

There are 3 ways PHP can be invoked from Apache:

1) as a module - this involves linking the php interpreter against a library of hooks published by the webserver

2) CGI - the webserver starts up an instance of the interpreter for each request and passes parameters to the interpreter via stdin, the command line and environment variables, stdout is sent to the client and stderr should be written to the error_log

3) fastCGI - this eliminates the overhead of starting a new process for each request - the interpreter runs as a daemon

CGI is the simplest to implement but does not scale/perform well, the module would be the hardest by far. FastCGI is nearly as fast as the module approach. CGI and fastCGI are open, well documented APIs.

There are other ways of achieving your goal - e.g. Quercus

C.

symcbean
Aha, this makes a lot of sense. Thanks! I'll look into this. I might just try to get the CGI approach working and then look into FastCGI as I did look at their specification the other day but found it very confusing, perhaps I was looking at the wrong place.
Sbm007