cgi死了吗？

Question

好的，让我们更温和地说：cgi（通用网关接口）是遗产吗？

是？没有？

在什么情况下，从今天开始的项目（一个不需要与遗留系统或库交互的项目）使用cgi？

Answer 1

实际上远非死亡。尽管存在开销，但许多虚拟Web托管公司现在将PHP作为CGI运行以考虑安全性，因为它可以与suEXEC一起使用。 suEXEC表示您的脚本在您的实际Unix用户权限下执行，因此受操作系统权限分离的限制。这是一个很多更强大的安全模型，而不是特定于PHP的open_basedir替代方案。

此外，CGI是一个真正的简单且功能多样的界面，对它的支持永远不会从Web服务器出来。许多较新的接口（如FastCGI和SCGI）继承了CGI将HTTP标头和其他变量传递给Web应用程序并返回的方式。甚至PHP的SAPI也使用$_SERVER变量来模仿它。所以CGI不会消失，只是建立在它之上。

Answer 2

旧？绝对。死？嗯，这是生命支持。我怀疑它在可预见的未来真的会“死”。如果您的服务器没有其他运行Web应用程序的方法，并且您懒得配置它，您仍然可以使用CGI编写非常小类脚本。

还有什么原因？也许你有一个程序泄漏内存或资源像筛子，但你还是需要运行它，所以你确保通过每个请求结束进程来清理所有内容......

但严重的是，对于真正重要的事情，我认为使用持久化流程迁移到任何类型系统的好处都会大大超过成本。根据我的经验，它鼓励编写组织更好的代码，因为在CGI环境中，需要具有良好模块化应用程序的初始化转换为“不可接受的启动时间”。

Answer 3

它还没死。但fcgi似乎是更好的方法。虽然没有正式的支持，比如Apache。你需要使用side mods来使它工作。

Answer 4

我也不认为CGI死了。毕竟，所有主要的Web服务器都支持它。

启动CGI项目未提及的一个原因可能是知识产权保护。例如，您可能决定使用C ++编写CGI程序，并允许您的客户在不受您控制的服务器上安装该应用程序。

也许您的旧产品已经将大量业务实现为库。 （.dll，.so .lib .a等）在这种情况下，在实现Web界面时，坚持使用c / c ++实际上可能会更快上市。

也许，你在德尔福商店工作？如果你店里10个工程师中有10个人写了Delphi，用PHP编写新的应用程序可能不是你最快的上市途径。

因此，简而言之，在决定使用哪种技术为您的新产品时，许多变量都会发挥作用，包括：

• 谁是您的客户？
• 你的出发点是什么？
• 您的资产和资源是什么？
• 你喜欢什么？
• 您的软件需要与哪些界面联系？
• 如何部署应用程序？

Answer 5

CGI不太适合高性能。

但我的建议是忽略这一点，为支持多个SAPI的语言或库编写代码，然后使用最适合每种情况的内容。