phpwindowsapachefastcginssm

"No input file specified" for some versions of PHP


I have multiple versions of PHP installed as per this guide, that I wrote. Basically, it is an ApacheLounge installation talking to PHP via FastCGI on Windows 10. This used to let me run these PHP versions at the same time on different VirtualHosts. Apache calls the proper PHP version via FastCGI on these ports:

Everything Some of these had been working for a while after the installation. Yesterday I had to test a website on PHP 5.6, but the ouput was just a "No input file specified message" which, turns out, is not that much descriptive, as a quick google search confirmed.

So I started a systematic approach. I created a VirtualHost for every PHP version, with just a index.php file with an echo statement. I tested all PHP versions installed, and all PHP5 versions did not work, while PHP7 versions worked as usual.

I removed all custom configuration files. No change.

I served a simple index.html file, and that works on all VirtualHosts. About PHP, no change.

I thought it was PHP 5.x bug, but after I rebooted my PC, the PHP 5.2 version started working. I stopped, removed and reinstalled some of the Windows Services create via NSSM, with no change.

This is what I think I know:

Any idea about how to debug this configuration, or about what is going wrong is appreciated.

Thank you.


Solution

  • This answer is about what I discovered above the issue, and how it is working for me.

    On this post and elsewhere on the net I found the advice to leave the doc_root in php.ini commented out:

    ;doc_root = 
    

    That works, in fact that's the configuration I use for all the abovementioned PHP 7.x installations, and for PHP 5.2 too. However, thats does not work for PHP 5.3 to 5.6.

    Reality is, for those versions of PHP, Apache's DocumentRoot and PHP's doc_root directives must match exactly.

    It was not easy to get here, due to the amount of deceiving or plain wrong information I found on the web (mostly due to PHP changing behavior from version to version):

    I hope this information is useful.

    NOTE:

    It took me a lot of time to solve this issue. One technique that I found useful is to increase Apache log level to trace8, as suggested here:

        LogLevel trace8