Is cgi dead? [closed]

Answer 1

It is not quite dead. But fcgi looks like much better approach. Though not officially supported by, say, Apache. You need to use side mods to get it to work.

Answer 2

It's far from dead actually. Despite the overheads, many virtual web hosting companies are now running PHP as CGI for security considerations, because it can be used with suEXEC. suEXEC means that your scripts execute under your actual Unix user privileges, and thus are restricted by the operating system's privilege separation. This is a much more robust security model than the PHP-specific open_basedir alternative.

Also, CGI is a really simple and quite versatile interface, support for it is never going out from web servers. Many newer interfaces like FastCGI and SCGI inherit the way that CGI passes HTTP headers and other variables to the web application and back. Even PHP's SAPI mimics this with its $_SERVER variable. So CGI is not going away, it is just being built upon.

Answer 3

Legacy? Absolutely. Dead? Well, it's on life support. I doubt it will really "die" in the forseeable future. You might still use CGI to write a very small sort of script if you've got a server with no other means of running a webapp and you're too lazy to configure it up.

What's another reason? Maybe you've got a program that leaks memory or resources like a sieve but you need to run it anyway, so you make sure everything is cleaned up by ending the process every single request...

But seriously, for things that really matter, I think the benefits of moving to any sort of system with persistent processes outweigh the costs by quite a bit. And in my experience, it encourages writing better-organized code as well, because the kind of initialization you need to have a nicely modular application translates to "unacceptable startup time" in a CGI environment.

Answer 4

I wouldn't consider CGI dead either. After all, it is supported by all major web servers.

One reason not mentioned for starting a CGI project might be Intellectual Property protection. For example you may decide to write a CGI program in C++ and allow your customer to install the application on a server not controlled by you.

Maybe your legacy product has tons of business implemented as libraries. (.dll, .so. .lib. .a etc) In this case, it may actually be faster to market to stick with c/c++ when implementing a web interface.

Perhaps, you work in a Delphi shop? If 10 out of 10 engineers in your shop write Delphi, writing your new application in PHP may not be your fastest path to market.

So, in short, many variables come into play when deciding what tech to use for you new product including:

• Who's your customer?
• What is your starting point?
• What are your assets and resources?
• What do you enjoy?
• What does your software need to interface with?
• How will the application be deployed?

Answer 5

CGI is not very well suited for high performance.

But my advice is to ignore that, write for a language or library that supports multiple SAPIs, and then use what fits best for each situation.