httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: Summary: Broken FastCGI with httpd
Date Wed, 18 Jan 2017 07:46:55 GMT
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


> Am 17.01.2017 um 23:16 schrieb Jacob Champion <>:
> (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:
> 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
> 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]
> [2]
> [3]
> [4]

View raw message