I'm using Debian 9 with PHP-FPM 7.0.26-2 & 5.6.32-1 from repository deb.sury.org. The same configuration is working fine on a Debian 8 server with PHP-FPM 5.6.30

  • I've copied the pool.d/user.conf from that server.
  • Both php.ini files are having cgi.fix_pathinfo=1.
  • The parameter is also forced using php_admin_value[cgi.fix_pathinfo] = 1.
  • Both servers uses this pool similarly from <VirtualHost> context with:

    ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:/run/php/user.sock|fcgi://localhost/home/user/public_html

Now, there's an AJAX page that needs to read path from PATH_INFO (possibly PATH_TRANSLATED). However, while these variables have correct content on the Debian 8 server:

string(14) "/path/ajax.php"
string(25) "/path/ajax.php/para/meters"
string(12) "/para/meters"
string(34) "/home/user/public_html/para/meters"

They seem to work differently on the fresh Debian 9 + dub.sury.org:

string(25) "/path/ajax.php/para/meters"
string(22) "/home/user/public_html"

And the prameters ORIG_SCRIPT_NAME and PATH_INFO are completely missing.


It was the way I used the proxy_fcgi. As explained in the examples for mod_proxy_fcgi:

You can also force a request to be handled as a reverse-proxy request, by creating a suitable Handler pass-through. - - The benefit of this form is that it allows the normal mapping of URI to filename to occur in the server, and the local filesystem result is passed to the backend. When FastCGI is configured this way, the server can calculate the most accurate PATH_INFO.

So I replaced my

ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:/run/php/user.sock|fcgi://localhost/home/user/...

with a Handler & Worker:

    <FilesMatch "\.php$">
            SetHandler  "proxy:unix:/run/php/user.sock|fcgi://localhost"
    <Proxy "fcgi://localhost/" enablereuse=on max=10>

Now all the AJAX request are working fine.

BONUS: If some knows why the ProxyPassMatch was able to calculate the the PATH_INFO before on my Debian 8 / Apache 2.4.10 / PHP-FPM 5.6.30 but not with Debian 9, that would be awesome.

| improve this answer | |
  • I have exactly the same problem. PATH_INFO was not passed after I upgraded to Debian 9 and set my Apache config with ProxyPassMatch "^/(.*\.php(/.*)?)$" "unix:/var/run/php/php7.0-fpm.sock|fcgi://localhost/var/www/" – klor Oct 13 '18 at 18:48
  • I'm glad, if this was helpful. – Esa Jokinen Oct 13 '18 at 19:01

As it is decribed on:


The reason, why the ProxyPassMatch does not set the PATH_INFO is the following:

Environment Variables

In addition to the configuration directives that control the behaviour of mod_proxy, there are a number of environment variables that control the FCGI protocol provider:

  • proxy-fcgi-pathinfo: When configured via ProxyPass or ProxyPassMatch, mod_proxy_fcgi will not set the PATH_INFO environment variable. This allows the backend FCGI server to correctly determine SCRIPT_NAME and Script-URI and be compliant with RFC 3875 section 3.3. If instead you need mod_proxy_fcgi to generate a "best guess" for PATH_INFO, set this env-var. This is a workaround for a bug in some FCGI implementations. This variable can be set to multiple values to tweak at how the best guess is chosen (In 2.4.11 and later only):

    • first-dot: PATH_INFO is split from the slash following the first "." in the URL.

    • last-dot: PATH_INFO is split from the slash following the last "." in the URL.

    • full: PATH_INFO is calculated by an attempt to map the URL to the local filesystem.

    • unescape: PATH_INFO is the path component of the URL, unescaped / decoded.

    • any other value: PATH_INFO is the same as the path component of the URL. Originally, this was the only proxy-fcgi-pathinfo option.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.