2.4.23 broke an FCGI corner case (Re: [Bug 59815])

[Jacob Champion <ch...@gmail.com>]

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

Re: 2.4.23 broke an FCGI corner case (Re: [Bug 59815])

[Eric Covener <co...@gmail.com>]

On Fri, Jul 8, 2016 at 4:21 PM, Jacob Champion <ch...@gmail.com> wrote:
> 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.
>

Committed a cleanup of r->fname in proxy_fcgi and proposed for 2.4.x.

Re: 2.4.23 broke an FCGI corner case (Re: [Bug 59815])

[Jacob Champion <ch...@gmail.com>]

On 07/08/2016 01:21 PM, Jacob Champion wrote:
> 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.

Following up on this... There's a workaround patch that has been 
backported, but I'd still like to know why this is happening. Are there 
any other bugs that can show up if the proxy canonicalization doesn't 
happen?

--Jacob