Have you even TRIED it? I have. With PHP-FPM as well as that Perl script FPM. All works as expected.
> On Feb 8, 2017, at 3:27 PM, Jacob Champion <champio...@gmail.com> wrote: > > On 02/08/2017 12:10 PM, Jim Jagielski wrote: >> Doesn't the below make it work without changes. >> >> #define FCGI_MAY_BE_FPM(dconf) \ >> (dconf && \ >> ((dconf->backend_type == BACKEND_DEFAULT_UNKNOWN) || \ >> (dconf->backend_type == BACKEND_FPM))) > > No. (To "make it work" we have to cover a gigantic number of use cases, not > just PHP-FPM, which is probably why we're talking past each other.) > > With your proposed backport, any users who were able to start using FastCGI > backends that required an "actual" SCRIPT_FILENAME, in the 2.4.21 or later > timeframe, will still have to modify their configs to specify a generic > FastCGI backend so that the "proxy:fcgi" stripping can kick in. Existing > PHP-FPM users don't change their config, sure, but they'll see yet another > behavior change because of the new fixup, which is just too risky IMO. > > Compare that to a complete reversion to the previous behavior, plus the > addition of the new FCGI SetEnv directive. The users requiring an "actual" > SCRIPT_FILENAME will be able to set it manually, which is no worse than > having to set the new Backend directive (better, actually, because > SCRIPT_FILENAME has no globally accepted meaning). Existing PHP-FPM users are > guaranteed the *exact* behavior they saw before 2.4.21, making it less risky > to upgrade. > > --Jacob
