FastCGI vs Apache's PHP engine ?

From: Rod 
What are the pros and cons of each approach?

Using Opera's mail client:

=============================================================== From: Mike Harrison ------------------------------------------------------ PHP as an Apache module gives you the ability to modify apache headers, which makes doing basic auth, browser cache and cookie manipulation, redirects and such a little easier. I haven't played with FastCGI in a long time, but it used to be used for running things only as a CGI, wich is theoretcially safer/easier for the hosting provider which is why 1and1 and some other cheaper high volume web hosts use it on the cheap accounts. Disclaimer: I haven't had to extract something from 1and1 in a few years because of this, so maybe they have changed. But they used to.

=============================================================== From: Rod ------------------------------------------------------ Well I'm leaning nginx which has to use FastCGI or PHP-FPM. One site I consulted thinks it is more secure and positively hates .htaccess logic. But mutual friends of us both say thats crazy. Personally I'm Tabla Rosa on the subject. On Fri, 11 Oct 2013 10:53:33 -0400, Mike Harrison wrote:

=============================================================== From: ------------------------------------------------------ Quoting Rod : from what I remember... CGI: CGI used to be out of process: ie, the web server had to do a context switch by forking the process, execv() the cgi and communicate via pipes. This, however, has several benefits, one of which is process isolation -- your CGI can bomb and it won't affect your web server. The downside is that all those shared libraries and initialization need to be done for every invocation (request). Using specialized SUID wrapper programs, you can configure your CGI to run as a different user: apache-httpd can run the accounting cgi program as Bob. Apache Module: PHP initially was implemented as a CGI, till Apache's 2.0 modules came out. Then PHP was handled in-process via a thread by a module (dynamically loaded library). This meant that there was less context switching, however, since it was a thread and not a new process, this mean the PHP app-space could technically corrupt the Apache server's app-space -- since they were the same space. Also, this means that whatever user the Apache server is running as, is also the user that the PHP script will run as. These risks were overshadowed by the increase in speed due to the lack of context switching and forking. Enter FastCGI. Fast CGI handled the issues with CGI by using a native module (dynamically loaded library) of the web server that keeps a communication stub in-context with the web server. The communication stub then forks off whatever "fastcgi" applications you have configured as long-running processes. There are various configurations of this. The simplest version is like a perl script that basically loops: while (FCGI::accept >= 0) { # body of response loop } As long as fastcgi is configured to send requests to that script, that script will run forever and continue to process requests. You can configure multiple "children" to handle multiple request loops. I'm sure they do some nifty thread tricks now, but I'm not up-to-date on those (I just assume they've migrated to that). There should also be API's to communicate back to the parent FastCGI stub thread that lives inside the web server's app-space. Thus, modern implementations should give you the same flexibility that Apache modules would give you -- granted, it might be slightly more complex to call (just an assumption). What this does solve three things: * context switching: initialization, process creation and shared lib loading * process isolation * FastCGI processes can run as a DIFFERENT user than the web server so you in effect, get the best of Apache modules AND CGI. The risk, however, is that it's slightly more complex to configure. By extension, this means it might be slightly more complex to troubleshoot. However, it's been around for YEARS, and therefore, there is A LOT of support data out there if you search for it. --b

=============================================================== From: Mike Harrison ------------------------------------------------------ .htaccess logic. Most of what people now do in .htaccess files is a kludge for shared = hosting apache configs. Nasty klutzy ways to do things for people on a = shared web server with the actual apache configs controlled by others.=20= For anything beyond a normal website/application, you should be running = your own server/configs/etc.. for general purpose website and small = scale applications: it's a religious difference that doesn't really = matter.=20 And I've seen the hairiest nastiest stuff ever done in .htacess files = with redirect logic..=20