设置IIS以使用CGI

在IIS上运行CGI有十个简单的步骤：

1)安装Inte.net Service Manager。
2)从列表中选择WWW Servive。
3)选择Properties/Service Properties命令。
4)单击Directories标签。
5)单击Add按钮。
6)指定自己的cgi-bin目录的完整路径（例如，c:webfilesscripts）。
7)使用/scripts作为目录别名。
8)选中Execute检查框。
9)单击OK保存修改。
10)将自己的CGI程序放在c:webfilesscripts中并在HTML中作为/scripts/someprogram.exe引用。
在使用IIS时经常出现的问题与设置IIS没太大关系而是和基本的操作系统功能有很大关系。IIS与底层的操作系统联系很紧密，即使已经设置为服务，Web服务器基本上是作为应用程序来运行的，通常只有一个用户安全环境，Web服务器能访问到的与Web服务器下的CGI程序能访问到的内容几乎没什么不同（这类似于UNIX环境，在UNIX环境下，很重要的一点就是不要将Web服务器作为root来运行）。IIS的工作很像一个扩展的文件系统。每个用户有自己的权限。CGI程序在执行该程序的访问者的用户安全环境中运行。对于未验证的页面，这就是缺省提供的“无名的”用户，而对验证的页面，安全环境就像用户位于服务器控制台前手工运行该程序一样。使大部分初学者犯错误的正是这种额外的安全层次。

IIS管理员最常抱怨的一个错误信息是"The Application misbehaved by not returning a complete set of headers"。错误消息接下来列出服务器接收到的头标--一般是个空的清单。这种讨厌的不明确的错误有一个直接的原因，不过这个原因与CGI脚本的错误操作没有一点关系。如果因为某种原因某个CGI脚本不能运行，它就不能产生任何头标。IIS将错误的责任推在脚本身上，实际上却几乎总是服务器管理员的错。CGI脚本需要访问系统DLLs、系统的临时目录以及它们使用的任何其他资源。如果该脚本是按静态约束进行编译的，那么除非所有组件均可用，否则操作系统不会装载该程序的。如果系统管理员锁紧了安全级使得脚本不能装载它的DLLs，那么脚本就不能运行。当脚本不能运行时，它也就不产生任何头标了（或者其他的输入），从而导致出现本段开头引用的错误消息。

如果管理员是在一个安全目录中运行脚本的（安全目录即是一个需要单独用户验证才能访问的目录），那么每个可能访问系统的用户都必须有下列安全权限。如果是无名地运行脚本，那么只有无名用户需要这些权限：

.对%systemroot%system（一般为c:winntsystem）的读权限
.对%systemroot%system32（一般为c:winntsystem32）的读权限
.对临时目录（一般为c:temp）的修改权限
.对Web根的读权限
.对CGI目录的修改权限
如果在有了这些访问权限之后仍然出问题，可以进一步临时给特殊的用户帐号Everyone赋予这些目录的修改权限。如果问题解决了，就可以认定是少了一个步骤（或一个用户）。纠正问题然后慢慢回收权限直至服务器重新安全。

原文转自：http://www.ltesting.net