从虚拟/自定义“Web 服务器”调用 PHP
基本上,我试图弄清楚如何从“Web 服务器”调用 PHP。
我已阅读文档,但没有多大帮助。
据我所知,有三种方法可以调用 PHP:
- 通过命令行(例如:
php -f "/path/to/script.php"
) - 通过 CGI(??) / via FastCGI (???)
- 通过网络服务器(例如:Apache)模块
所以让我们从 CGI 开始。也许我只是瞎了眼,但规范并没有提到 Web 服务器到底如何将数据(标头和回调)传递给实现 CGI 的东西。 FastCGI 的情况更糟。
接下来,我们有特定于服务器的模块,我什至不知道要搜索什么,因为所有线索最终都无处可去。
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) to 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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
调用 CGI 脚本非常简单。 PHP 有一些特性,但您基本上只需要设置环境变量列表,然后调用 PHP-CGI 二进制文件:
其中大多数都是样板文件。
SCRIPT_FILENAME
是将实际的 php 文件名传递给 PHP 解释器的方式,而不是作为 exec 参数。对于 PHP 来说至关重要的还有非标准变量REDIRECT_STATUS=200
。对于 GET 请求,您只需要环境变量。对于 POST 请求,您只需将 HTTP 请求正文作为
stdin
通过管道传输到执行的 php-cgi 二进制文件。返回的stdout
是由不完整的 HTTP 标头、\r\n\r\n 和页面正文组成的 CGI 响应。(仅凭记忆。可能还有一些问题。)
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:
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 variableREDIRECT_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 returnedstdout
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 可能是最好的选择,因为它的使用非常明智,它会给你语言独立性(例如,你可以稍后使用 Ruby),并且它是 详细记录 与 很多 示例。
如果您确实愿意,您可以编写自己的 服务器 API,但它比实现 FastCGI 更棘手,并且有几个缺点。
我根本不会理会直接的 CGI,FastCGI 的存在是有原因的。
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.