能正常使用普通的功能后，再通过 chcon 设置 cgi 文件的 context 为
httpd_sys_script_exec_t 即可。chcon -R -t httpd_sys_script_exec_t cgi-bin/
2) apache 错误提示：.... malformed header from script. Bad header=
根据提示说明有 header

 

有问题，查看文件输出的第一句话是什么，应该类似于如下

Content-type: text/plain; charset=iso-8859-1\n\n 
或者 Content-type:text/html\n\n
注意：声明好 Content-type 后要输出两个空行。
3）apache

 

错误提示： Exec format error

脚本解释器设置错误。脚本第一行应该以'#!解释器路径'的形式, 填写脚本解释器的路径，
如果是 PERL 程序，常见的路径为: #!/usr/bin/perl   

或 #!/usr/local/bin/perl 如果是 PHP 程序，

不需要填写解释器路径，系统会自动找到 PHP。

2. Fastcgi 模式

fast-cgi 是 cgi 的升级版本，FastCGI 

 

像是一个常驻 (long-live) 

 

型的 CGI，它可以一直执行

 

着，只要激活后，不会每次都要花费时间去 fork 

 

一次 (

 

这是 CGI 

 

最为人诟病的 fork-and-

execute 模式)

 

。

FastCGI 的工作原理是：
(1)、Web Server 启动时载入 FastCGI 进程管理器【PHP 的 FastCGI 进程管理器是 PHP-
FPM(php-FastCGI Process Manager)】（IIS ISAPI 或 Apache Module);
(2)、FastCGI 进程管理器自身初始化，启动多个 CGI

 

解释器进程 (在任务管理器中可见多

个 php-cgi.exe)并等待来自 Web Server 的连接。
(3)、当客户端请求到达 Web Server 时，FastCGI 进程管理器选择并连接到一个 CGI 解释器。
Web server 将 CGI 环境变量和标准输入发送到 FastCGI 子进程 php-cgi。
(4)、FastCGI 子进程完成处理后将标准输出和错误信息从同一连接返回 Web Server。当
FastCGI 子进程关闭连接时，请求便告处理完成。FastCGI 子进程接着等待并处理来自
FastCGI

 

进程管理器（运行在 WebServer 中）的下一个连接。在正常的 CGI 模式中，php-

cgi.exe 在此便退出了。
在 CGI

 

模式中，你可以想象 CGI 通常有多慢。每一个 Web 请求 PHP 都必须重新解析

php.ini、重新载入全部 dll 扩展并重初始化全部数据结构。使用 FastCGI，所有这些都只在
进程启动时发生一次。一个额外的好处是，持续数据库连接(Persistent database connection)
可以工作。

Fastcgi 的优点：

1）从稳定性上看, fastcgi 是以独立的进程池运行来 cgi,单独一个进程死掉,系统可以很轻
易的丢弃,

 

然后重新分 配新的进程来运行逻辑.

2）从安全性上看,Fastcgi 支持分布式运算. fastcgi 和宿主的 server 完全独立, fastcgi 怎么
down 也不会把 server 搞垮.
3）从性能上看, fastcgi 把动态逻辑的处理从 server 中分离出来, 大负荷的 IO 处理还是留给
宿主 server, 这样宿主 server 可以一心一意作 IO,对于一个普通的动态网页来说, 逻辑处理
可能只有一小部分, 

 

大量的图片等静态

FastCGI 缺点：说完了好处，也来说说缺点。从我的实际使用来看，用 FastCGI 模式更适

 

合生产环境的服务器。但对于开发用机器来说就不太合适。因为当使用 Zend Studio 调试程

 

序时，由于 FastCGI

 

会认为 PHP

 

进程超时，从而在页面返回 500 错误。这一点让人非常恼

 

火，所以我在开发机器上还是换回了 ISAPI 模式。

安装 fastcgi 模式：

安装 apache 路径是/usr/local/httpd/