Thanks for the nice summary, Jacob. I find the topic of cgi in our server surprisingly complex. Sometimes mod_http2 stumbles on "details" like conn->id to identify requests that Seemed a Good Idea at the time.
Would it make sense to narrow down the setups to a few blessed ones that become part of our tests? Stefan > Am 17.01.2017 um 23:16 schrieb Jacob Champion <[email protected]>: > > (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
