(This conversation is currently spread over Bugzilla, IRC, GitHub, and
php-internals. Here's my attempt at summarizing it for all of you. If
you have no interest in CGI or FastCGI, stop reading now.)
== Backstory ==
Back in May I was testing some FCGI backends with mod_proxy_fcgi, and I
found a backend called fcgiwrap that didn't work. That conversation is
in . SCRIPT_FILENAME was being set to a value beginning with
"proxy:fcgi://host:port", and that didn't make any sense. We patched the
problem in 2.4.21 by stripping the weird prefix and called it good.
Fast forward to find that in *some* cases, SCRIPT_FILENAME could still
contain weird values that didn't make any sense (in this case, a query
string), because proxy canonicalization doesn't run correctly in
per-directory rewrites. The conversation is in . We stripped the
query string and called it good.
Fast forward to find that in *some* cases involving mod_rewrite, PHP-FPM
now refuses to operate correctly with mod_proxy_fcgi. That conversation
is in . There is no patch, and we can't call this good anymore...
== Problem ==
PHP-FPM does a lot of gymnastics to get around old CGI incompatibilities
with mod_fastcgi, et al. It was using our accidental "proxy:fcgi//"
prefix as a marker to say "this is a new Apache server with
mod_proxy_fcgi; don't do some of the weird fixups". Without the marker,
in specific cases PHP-FPM will assume it is talking to an older
incompatible FCGI module and "fix" things incorrectly.
I looked to see if there was a way we could keep the current behavior
and trick current PHP-FPM deployments into not enabling their "quirks
mode" fixups. I don't see any, not without breaking other valid use
cases. For now, I've filed a Showstopper against 2.4.x with the
intention of reverting the change entirely for 2.4.26.
== Moving Forward ==
I think the best way to make both us and our users happy is to talk to
the PHP devs and fix both sides at once. To fix our side, I think we
have to do two things:
1) Fix the CGI 1.1 incompatibilities in all of our first-party FCGI
modules so backends don't have to perform any fixup.
Those quirks have their own (in)famous bug:
in which the reporter melts down after three years of inaction.
The difficulty here is that there are a bunch of supported ways to
invoke FCGI (Action, SetHandler, ProxyPass, RewriteRule), all of which
seem to define CGI variables to different values in different situations.
2) Define what SCRIPT_FILENAME means.
SCRIPT_FILENAME isn't actually a CGI 1.1 standard variable. We appear to
have defined it as "whatever r->filename contains", so we've effectively
coupled our implementation details to external clients. PHP-FPM and
fcgiwrap, for example, assume that SCRIPT_FILENAME should point to the
script that should be executed to handle the request. We need to
These fixes probably can't be enabled by default until we go through a
compatibility version bump. But I've started chatting with people on the
PHP side  and we can hopefully fix these sorts of things once and for