I have found an alternative method that works nicely, only passes .php files to PHP-FPM and allows the variables to pass. ProxyPassMatch ^(.*\.php)$ fcgi:// 127.0.0.1:9000/www/danielhe/danielhe.com/cookie.danielhe.com$1
This is really weird though, because when it's put outside of a vhost, it works properly, but when I put it inside one, it gives a 404. Error logs show up for the same URL, but when put inside the vhost, it says it does not exist. Any idea why? vhost: AH00128: File does not exist: proxy:fcgi:// 127.0.0.1:9000/www/danielhe/danielhe.com/cookie.danielhe.com//index.php outside of vhost: AH00947: connected /www/danielhe/danielhe.com/cookie.danielhe.com//index.phpto 127.0.0.1:9000 On Mon, Mar 5, 2012 at 9:34 AM, Mark Montague <[email protected]> wrote: > On March 3, 2012 7:22 , Daniel <[email protected]> > <[email protected]>wrote: > > Thank you, I just realized that earlier, as I thought Location /www/ meant > server side. > It works, however it passes all traffic through PHP-FPM and gives a > "Access denied." message on static files, and does not allow passing > variables through the URL with the mod_rewrite method. > > An alternative rewrite, RewriteRule ^/?(.*\.php)$ fcgi:// > 127.0.0.1:9000/www/$1 [P,L], allows static files to work, but breaks PHP > files when you try to pass variables, or even add a symbol, as like before. > (ex: info.php?) > > Is there any 'fully-working' solution for PHP-FPM with Apache 2.4? None > of the methods seem to work as intended. Either static files do not work, > or variables cannot be passed. > > > I have PHP-FPM fully working with a patched Apache 2.3.12, so it should be > workable with 2.4. > > For passing static files, this is just a guess, but make sure you have > default_mimetype set to an empty value in php.ini. If this does not help, > let me know and I'll look at my configuration more closely. > > For the RewriteRule not passing query strings (variables), see > https://issues.apache.org/bugzilla/show_bug.cgi?id=51077 Unfortunately, > the person with commit access who looked at this did not "see the > rationale" for it, and I have not had time to go back and install the > entire testing framework (which is apparently a big pain, according to the > recent thread on the topic) to see what tests the patch breaks and how/why > it breaks them. I do hope to go back and take another stab at this, but I > can't say when it will be, so if anyone else wants to, please feel free. > > -- > Mark Montague > LSA Research Systems Group > University of Michigan > [email protected] > >
