[PPP-17663] PHP FPM does not work with PathInfo - leading to 404 errors

[H9k]

Hello there,
I switched all sites from FastCGI to FPM, only to notice that about 5% of them use seo-friendly URLs without mod_rewrite/.htaccess, meaning that they have URLs like this: http://www.blabla.tld/index.php/about-us
I think all of them are Joomla installations btw.
Anyhow, when using PHP with the FPM handler, I get 404 errors, because it does not interpret that index.php as being a file. When switching back to FastCGI (same PHP version) the website works fine again.
Now I noticed in the apache vhost config file there is such a line

ProxyPassMatch ^/(.*\.php)$ unix:///var/www/vhosts/system/blabla.tld/php-fpm.sock|fcgi://127.0.0.1:9000/var/www/vhosts/blabla.tld/httpdocs

I suspect that regex is to blame or something? Is this a a known limitation of FPM or just a Plesk bug?

 

[paulieG]

Hi,

We resolved this by adjusting our templates to :

ProxyPassMatch ^/(.*\.php(/.*)?)$ ...

More info : https://wiki.apache.org/httpd/PHP-FPM

 

[paulieG]

I should add it appears that ProxyPassMatch is being parsed/actioned before .htaccess rewrite rules, as otherwise this should work!

 

[H9k]

@paulieG nope, .htaccess works fine with FPM, but websites using PathInfo (now I know the correct term hehe) work without .htaccess and rewrite rules.
It seems that Plesk should correct its ProxyPassMatch to allow for PathInfo to work under FPM, the way you wrote it should work fine.

 

[vlikhtanskiy]

Hello,

I confirm it's a bug with ID PPP-17663 in our internal tracker. I hope it'll be fixed in nearest microupdates.

 

[H9k]

awesome

 

[H9k]

Just installed 12.5.30 Update 4, but the bug is still there.

 

[vlikhtanskiy]

We don't force reconfiguration of all sites during microupdate installation.

You can run:
# plesk repair web -domains-only
To force reconfiguration of all sites.

 

[H9k]

Did not solve the problem. Also tried switching PHP back to FastCGI and to FPM again, but FPM is still broken.

 

[vlikhtanskiy]

Sorry for misleading you. Just checked again: this bug wasn't included in MU#4 but will be included in MU#5.