(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 [1]. 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 [2]. 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 [3]. 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:
https://bz.apache.org/bugzilla/show_bug.cgi?id=51517
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
standardize it.
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 [4] and we can hopefully fix these sorts of things once and for
all.
--Jacob
[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=59618
[2]
https://lists.apache.org/thread.html/87fd8d1dc208b7d74fadf7b3929e71cfd7279c5c5b9b2566386cb684@%3Cdev.httpd.apache.org%3E
[3] https://github.com/apache/httpd/commit/cab0bfbb#commitcomment-20393588
[4] https://github.com/php/php-src/pull/694#issuecomment-271963956
