httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <champio...@gmail.com>
Subject 2.4.23 broke an FCGI corner case (Re: [Bug 59815])
Date Fri, 08 Jul 2016 20:21:04 GMT
On 07/07/2016 05:11 AM, bugzilla@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

Mime
View raw message