Call PHP from virtual/custom "web server"
Basically, I'm trying to figure out how PHP can be called from a "web server".
I've read the documentation, but it didn't help much.
As far as I can tell, there are three ways to invoke PHP:
- via command line (eg:
php -f "/path/to/script.php"
) - via CGI(??) / via FastCGI (???)
- via a web server (eg: Apache) module
So let's start with CGI. Maybe I'm just blind, but the spec doesn't mention how on Earth the web server passes data (headers & callbacks) t开发者_开发技巧o the thing implementing CGI. The situation is even worse with FastCGI.
Next up, we have server-specific modules, which, I don't even know what to search for since all leads end up nowhere.
Invoking a CGI script is pretty simple. PHP has a few peculiarities, but you basically only need to setup a list of environment variables, then call the PHP-CGI binary:
setenv GATEWAY_INTERFACE="CGI/1.1"
setenv SCRIPT_FILENAME=/path/to/script.php
setenv QUERY_STRING="id=123&name=title&parm=333"
setenv REQUEST_METHOD="GET"
...
exec /usr/bin/php-cgi
Most of them are boilerplate. SCRIPT_FILENAME
is how you pass the actual php filename to the PHP interpreter, not as exec parameter. Crucial for PHP is also the non-standard variable REDIRECT_STATUS=200
.
For a GET request you only need the environment variables. For a POST request, you simply pipe the HTTP request body as stdin
to the executed php-cgi binary. The returned stdout
is the CGI response consisting of an incomplete HTTP header, \r\n\r\n, and the page body.
(Just from memory. There maybe a few more gotchas.)
FastCGI is probably the best option since it's so wisely used, it would give you language independence (you could drop in Ruby later, for example) and it's well documented with lots of examples.
You could write your own Server API if you really want, but it's trickier than implementing FastCGI and has several disadvantages.
I wouldn't bother at all with straight CGI, FastCGI exists for a reason.
精彩评论