httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: svn commit: r1782209 - /httpd/httpd/branches/2.4.x/STATUS
Date Wed, 08 Feb 2017 20:31:28 GMT
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 <> 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

View raw message