What is CGI and What is FastCGI?

There was a long rant in the wp-testers mailing list today talking about how we weren’t helpful to someone who was getting a “500 Internal Server Error” message after installing WordPress.  After complaining about our helpfulness and some bragging about past income levels, the poster said:

Quickly about the Internal Server Error.  It most probably has to do with using fast graphics on a server.  Older version of Apache like 1.333 are still in use with major hosting sites.  Using fast graphics with this slopped together code from wordpress will quite often cause  500 errors by causing the server to time out on you.

I think the writer misunderstood the meaning of FastCGI.  I wrote this reply/post to help clarify it for him and for myself as well:

We old school programmers remember the term CGI as “Computer Graphics Interface” and how it related to the initial concepts that matured into the video card drivers supplied with Windows. In DOS, the games you ran each came with their own hand written drivers for the most popular cards. CGI was a standard for writing these drivers. I still have a CGI programming book on my shelf that talks about programming for the Trident, Matrox and Tseng Labs video cards. As a side note, CGI in the movie industry refers to Computer Generated Images – also graphics related.

But when talking about Web Servers, CGI is the Common Gateway Interface. It really has little or nothing to do with graphics. The CGI is basically how the server turns website requests into the execution of console programs and the passing of the results back to the browser. In my experience, straight CGI programming is most often done in PERL, but doesn’t have to be. CGI programs are separate and independent from the Apache server. They are executed and return a result. That’s it.

FastCGI is an extended version of the CGI that is optimized for speed and scalability. It has also been extended to allow the web server to run on one machine and the CGI calls to execute on another.

Where all this comes into play with PHP (and WordPress) is that PHP can be connected with Apache (or lighttpd or w/e) in different ways. It can be a module interfacing through Apache API calls. Or it could also be a CGI application. If connected to Apache via CGI, the PHP code is executed by the server as console calls to a separate PHP application. Since FastCGI is compatible with CGI, FastCGI can also be a chosen interface between PHP and Apache or whatever webserver you are using.

As all of this changes how PHP and your webserver talk, over the years there have been bugs in WP that were specific to FastCGI servers. However, a 500 Internal Server Error is simply the server saying “OK This is all screwed up and I have no idea what to do now.”. Yeah, maybe that has something to do with how FastCGI is setup, but it is even more likely that you are simply missing a bracket or comma in your .htaccess file.

So even if this question had been in the right forum, we couldn’t have helped the person.  When the question is ‘My server says “Something is screwed up”. How do I fix it?’, the best response we can offer will start with  “Ummmmm”.

Also, I’ve come to understand this stuff just through passing conversations with SysAdmins and random reading. So please correct me if I am wrong on any of this.