On Fri, Jul 8, 2016 at 4:21 PM, Jacob Champion <champio...@gmail.com> wrote: > On 07/07/2016 05:11 AM, bugzi...@apache.org wrote: >> >> https://bz.apache.org/bugzilla/show_bug.cgi?id=59815 > > > covener and I have been trading comments on IRC about this one. The summary > so far is that our latest release broke a use case where all of the > following are true: > > - FCGI requests are proxied via RewriteRule [P] > - the FCGI backend is PHP-FPM > - the RewriteRule is in a per-directory context > - a query string is part of the request > - there is no additional PATH_INFO (i.e. after the script path) > > Technically, it's a regression from 2.4.20 caused by r1748324. My patch > attempted to fix a long-standing bug in SCRIPT_FILENAME where the internal > proxy:fcgi prefix was being leaked to the backend. Unfortunately, in this > particular corner case, we still leak a query string in SCRIPT_FILENAME. And > it seems that since our "bug marker" of proxy:fcgi is gone, PHP-FPM isn't > fixing up the mistake for us anymore. > > The root cause appears to be (at least to me) that the proxy URL > canonicalization step does not run when a per-directory rewrite is used. > Instead, mod_rewrite simply hardcodes r->filename to include the query > string. With a server-context rewrite, the canonicalization step is invoked > correctly, which lets mod_proxy_fcgi remove the query string and set > PATH_INFO. > > The question is, why the difference? Is this done on purpose? It's not just > an FCGI problem; for example, HTTP proxy canonicalization doesn't run > correctly in per-directory rewrites either. It runs correctly in > server-context rewrites. > > There are a bunch of different approaches to fix this that we could take, > but I have very little experience with the mod_rewrite code base... I'm > hoping someone has some additional insight. >
Committed a cleanup of r->fname in proxy_fcgi and proposed for 2.4.x.
