On Jan 28, 2008 9:57 PM, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > Olaf van der Spek wrote: > > > > I agree that FastCGI is the better technical solution, I'm just > > stating that neither the Apache documentation nor the PHP > > documentation seems to state that. Even worse, they hardly document > > the FastCGI way at all. > > FastCGI is a technically subpar way to execute trusted, valid PHP.
Why? Isn't memory (and other resource) consumption a lot lower because you don't need a PHP 'engine' for every thread/process? Even valid PHP code can crash, given bugs in PHP itself. And I think tons of users sometimes run untrusted or invalid PHP. > People have always been under some preconception that it's good to run > untrusted code in-process within httpd, while numerous "vulnerability" > reports in the past (and many to appear over the future) all bear out > that it's a really stupid idea. Given that the alternatives (FastCGI) isn't well documented, I don't think that's strange. > FastCGI is also a so-so way to get around libraries which aren't thread- > safe, running worker or event mpm's. Of course, using the 21st century > equivalents of those libraries probably isn't a bad solution either. Olaf
