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.
--Jacob
