(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

Reply via email to