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
