httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel <>
Subject Re: [users@httpd] mod_proxy_fcgi + PHP-FPM on Apache 2.4 solution?
Date Mon, 05 Mar 2012 14:04:57 GMT
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://$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?

AH00128: File does not exist: proxy:fcgi://

outside of vhost:
AH00947: connected /www/danielhe/

On Mon, Mar 5, 2012 at 9:34 AM, Mark Montague <> wrote:

>  On March 3, 2012 7:22 , Daniel <> <>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://
>$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
>   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

View raw message