On 06/23/2017 01:22 PM, Jim Jagielski wrote:
This is cool. Thx. It's inline with what I was hoping to do.
No problem!
I'm curious though Since we never actually *run* php-fpm on the PHP script, we never see what PHP actually determines are these parameters, right?
So like you said on IRC: the entire point of PHP-FPM mode is to work with PHP as it exists today. But "work" means different things to different people. Some people just want the scripts to *run*; other people need the values of the envvars to remain exactly compatible because they use them within their scripts.
So the regression test for a default, unset BackendType doesn't really need to run FPM, because we can't change the envvar values we send by default anyway. (Because that would potentially break, and has already broken, users who are using those values for some other reason.) What we need to check instead is that the unset BackendType behaves exactly as 2.4.20 did, so that no users upgrading from pre-2.4.20 are broken by our latest release.
I don't see a need for an FPM mode at moment, because the 2.4.20 behavior that should become the default in 2.4.27 *seemed* to work for the vast majority of people. (I was the person who filed the proxy: prefix bug, and I have a better solution to that now with Eric's ProxyFCGISetEnvIf.) But we shipped FPM mode and I can't very well remove it. If you want FPM mode to do something differently from 2.4.20's behavior, it'd be good to explain what that is and why you want it.
(All that said, an integration test with FPM would be great to have on top of the regression test for obvious reasons. It just serves a different purpose.)
--Jacob
