但它仍然无法正常工作！
当您尝试从 Web 访问您的 CGI 程序时，您可能会在浏览器中看到四种基本情况
您的 CGI 程序的输出
太好了！这意味着一切都正常工作。如果输出正确，但浏览器没有正确处理它，请确保您在 CGI 程序中设置了正确的内容类型。
您的 CGI 程序的源代码或“POST 方法不允许”消息
这意味着您没有正确配置 Apache 以处理您的 CGI 程序。重新阅读有关 配置 Apache 的部分，并尝试找出您错过了什么。
以“禁止”开头的消息
这意味着存在权限问题。检查 Apache 错误日志 和下面有关 文件权限 的部分。
显示“内部服务器错误”的消息
如果您检查 Apache 错误日志，您可能会发现它显示“脚本标头过早结束”，可能还会伴随您的 CGI 程序生成的错误消息。在这种情况下，您将需要检查以下每个部分，以查看是什么可能阻止您的 CGI 程序发出正确的 HTTP 标头。
文件权限
请记住，服务器不是以您的身份运行的。也就是说，当服务器启动时，它以非特权用户的权限运行——通常是 nobody 或 www——因此它需要额外的权限才能执行您拥有的文件。通常，为文件提供足够的权限以便 nobody 可以执行它的方法是为每个人授予该文件的执行权限
chmod a+x first.pl
此外，如果您的程序从任何其他文件读取或写入任何其他文件，则这些文件需要具有正确的权限才能允许这样做。
路径信息和环境
当您从命令行运行程序时，您会有一些信息传递给 shell，而您无需考虑它。例如，您有一个 PATH，它告诉 shell 它可以在哪里查找您引用的文件。
当程序通过 Web 服务器作为 CGI 程序运行时，它可能没有相同的 PATH。您在 CGI 程序中调用的任何程序（例如 sendmail）都需要通过完整路径指定，以便 shell 在尝试执行您的 CGI 程序时能够找到它们。
这种情况的常见表现形式是 CGI 程序第一行中指示的脚本解释器（通常是 perl）的路径，它看起来像
#!/usr/bin/perl
确保这确实是解释器的路径。
在 Windows 上编辑 CGI 脚本时，可能会将行尾字符附加到解释器路径。确保文件以 ASCII 模式传输到服务器。如果这样做，由于无法识别的行尾字符被解释为解释器文件名的部分，可能会导致操作系统发出“找不到命令”警告。
缺少环境变量
如果您的 CGI 程序依赖于非标准 环境变量，您需要确保 Apache 传递了这些变量。
当您在环境中丢失 HTTP 标头时，请确保它们按照 RFC 2616 第 4.2 节的格式进行格式化：标头名称必须以字母开头，后面只能跟字母、数字或连字符。任何违反此规则的标头将被静默丢弃。
程序错误
大多数情况下，当 CGI 程序失败时，是因为程序本身存在问题。当您掌握了 CGI 的基本知识后，这种情况尤其如此，您不再犯上述两个错误。首先要做的是确保您的程序在通过 Web 服务器测试之前从命令行运行。例如，尝试
cd /usr/local/apache2/cgi-bin./first.pl
（不要调用 perl 解释器。shell 和 Apache 应该使用脚本第一行上的 路径信息 找到解释器。）
您首先看到程序写入的内容应该是一组 HTTP 标头，包括 Content-Type，后面跟着一个空行。如果您看到其他任何内容，Apache 将在您尝试通过服务器运行它时返回 Premature end of script headers 错误。有关更多详细信息，请参阅上面的 编写 CGI 程序。
错误日志
错误日志是您的朋友。任何出错都会在错误日志中生成消息。您应该始终首先查看那里。如果托管网站的位置不允许您访问错误日志，您可能应该将网站托管在其他地方。学会阅读错误日志，您会发现几乎所有问题都可以快速识别并快速解决。
Suexec
suexec 支持程序允许 CGI 程序在不同的用户权限下运行，具体取决于它们位于哪个虚拟主机或用户主目录中。Suexec 具有非常严格的权限检查，任何检查失败都会导致您的 CGI 程序以 Premature end of script headers 失败。
要检查您是否正在使用 suexec，请运行 apachectl -V 并检查 SUEXEC_BIN 的位置。如果 Apache 在启动时在那里找到一个 suexec 二进制文件，则 suexec 将被激活。
除非您完全了解 suexec，否则您不应该使用它。要禁用 suexec，只需删除（或重命名）由 SUEXEC_BIN 指向的 suexec 二进制文件，然后重新启动服务器。如果您在阅读了有关 suexec 的信息后，仍然希望使用它，那么运行 suexec -V 以找到 suexec 日志文件的位置，并使用该日志文件找到您违反的策略。