Hi,

First of all, sorry for the trouble if this ends up being a
misconfiguration/misunderstanding of the code on my side :)

>Are you saying that PHP-FPM requires that the r->filename
>AND the URL have that prepended? That seems weird
>and wrong to me...

Yep, but only the filename. Here is the relevant code in PHP
(php-5.5.8//sapi/fpm/fpm/fpm_main.c):

#define APACHE_PROXY_FCGI_PREFIX "proxy:fcgi://"
        /* Fix proxy URLs in SCRIPT_FILENAME generated by Apache
mod_proxy_fcgi:
         *     proxy:fcgi://localhost:9000/some-dir/info.php/test?foo=bar
         * should be changed to:
         *     /some-dir/info.php/test
         * See: http://bugs.php.net/bug.php?id=54152
         *      https://issues.apache.org/bugzilla/show_bug.cgi?id=50851
         */
        if (env_script_filename &&
            strncasecmp(env_script_filename, APACHE_PROXY_FCGI_PREFIX,
sizeof(APACHE_PROXY_FCGI_PREFIX) - 1) == 0) {
            /* advance to first character of hostname */
            char *p = env_script_filename +
(sizeof(APACHE_PROXY_FCGI_PREFIX) - 1);
         ...

So it expects to find "proxy:fcgi://" to then strip it. If only fcgi:// is
provided, no cleaning is performed and it results in the file not being
found. The code mentions a bug, marked as resolved, but I think only the
PATH_INFO-related part was fixed.


I added some debug messages to Apache to easily check the filename being
used in different configurations. I basically added a  ap_log_rerror in
the ap_add_common_vars function to intercept the value of the
SCRIPT_FILENAME delivered to PHP-FPM:


diff --git a/server/util_script.c b/server/util_script.c
index 3bc1b00..ce1ca33 100644
--- a/server/util_script.c
+++ b/server/util_script.c
@@ -243,13 +243,14 @@ AP_DECLARE(void) ap_add_common_vars(request_rec *r)
     apr_table_addn(e, "CONTEXT_PREFIX", ap_context_prefix(r));
     apr_table_addn(e, "CONTEXT_DOCUMENT_ROOT",
ap_context_document_root(r));
     apr_table_addn(e, "SERVER_ADMIN", s->server_admin); /* Apache */
+    ap_log_rerror(APLOG_MARK, APLOG_TRACE1, 0, r, "FILENAME USED TO DEFINE
SCRIPT_FILENAME: '%s'", r->filename);
     if (apr_table_get(r->notes, "proxy-noquery") && (q =
ap_strchr(r->filename, '?'))) {
         *q = '\0';
         apr_table_addn(e, "SCRIPT_FILENAME", apr_pstrdup(r->pool,
r->filename));
         *q = '?';
     }

I then tried different configurations and got the belo results:

* RewriteRule + my hack (not providing the socket in the RewriteRule, but
providing it in a <Proxy> section)
===================================================================================
- Configuration used:

<Proxy "unix:/path/to/www.sock|fcgi://backend-fpm"  timeout=300>
</Proxy>
RewriteRule ^(.*\.php(/.*)?)$  fcgi://concrete5-fpm/%{REQUEST_FILENAME} [P]

- Logged message:

[Mon Jan 27 09:52:50.409054 2014] [core:trace1] [pid 15743:tid 4389752832]
util_script.c(246): [client ::1:61686] FILENAME USED TO DEFINE
SCRIPT_FILENAME: 'proxy:fcgi://backend-fpm//tmp/foo/htdocs/info.php'

* UDS in RewriteRule with default worker
================================

- Configuration used:
RewriteRule ^(.*\.php(/.*)?)$
 unix:/path/to/www.sock|fcgi://backend-fpm/%{REQUEST_FILENAME} [P,NE]

- Logged message:
[Mon Jan 27 09:53:25.485081 2014] [core:trace1] [pid 15840:tid 4390289408]
util_script.c(246): [client ::1:61689] FILENAME USED TO DEFINE
SCRIPT_FILENAME: 'fcgi://backend-fpm//tmp/foo/htdocs/info.php'

* Using only ProxyPass:
===================

- Configuration used:
ProxyPass /backend-fpm
 "unix:/path/to/www.sock|fcgi://backend-fpm/tmp/foo/htdocs"

- Logged message:
[Mon Jan 27 09:56:07.786804 2014] [core:trace1] [pid 16127:tid 4389752832]
util_script.c(246): [client ::1:61699] FILENAME USED TO DEFINE
SCRIPT_FILENAME: 'proxy:fcgi://backend-fpm/tmp/foo/htdocs/info.php'

In all the configurations but the one with the default proxy worker the
SCRIPT_FILENAME is defined as
"proxy:fcgi://backend-fpm/tmp/foo/htdocs/info.php" (using ports instead of
UDS also preprend "proxy:")


Best regards,

Juanjo.



2014-01-26 Jim Jagielski <j...@jagunet.com>

> proxy:fcgi is what mod_rewrite send and the patch
> takes specific action to remove that 'proxy:' part.
> Are you saying that PHP-FPM requires that the r->filename
> AND the URL have that prepended? That seems weird
> and wrong to me...
>
> On Jan 26, 2014, at 10:49 AM, ryo takatsuki <ryotakats...@gmail.com>
> wrote:
>
> > Hi,
> >
> > I am checking the new patch (thanks again!) and I'm finding some issues
> trying to connect to PHP-FPM using the socket. The problem seems to be that
> the filename sent to the proxy is defined as "fcgi://localhost/..." where
> it usually is "proxy:fcgi://localhost/..." (being the last form the one PHP
> expects).
> >
> > It seems the "proxy:" prefix is stripped when the socket is extracted.
> The below patch fixes it but I'm not sure is the best solution:
> >
> > diff --git a/modules/proxy/proxy_util.c b/modules/proxy/proxy_util.c
> > index fb6426b..909c384 100644
> > --- a/modules/proxy/proxy_util.c
> > +++ b/modules/proxy/proxy_util.c
> > @@ -1959,8 +1959,8 @@ PROXY_DECLARE(int)
> ap_proxy_pre_request(proxy_worker **worker,
> >                      if (rv == APR_SUCCESS) {
> >                          char *sockpath =
> ap_runtime_dir_relative(r->pool, urisock.path);
> >                          apr_table_setn(r->notes, "uds_path", sockpath);
> > -                        r->filename = ptr+1;    /* so we get the scheme
> for the uds */
> > -                        *url = apr_pstrdup(r->pool, r->filename);
> > +                        r->filename = apr_pstrcat(r->pool,
> "proxy:",ptr+1, NULL);
> > +                        *url = apr_pstrdup(r->pool, ptr+1);
> >                          ap_log_rerror(APLOG_MARK, APLOG_TRACE2, 0, r,
> >                                        "*: rewrite of url due to UDS:
> %s", *url);
> >                      }
> >
> >
> > Regards,
> >
> > Juanjo.
> >
> >
> > 2014-01-22 Plüm, Rüdiger, Vodafone Group <ruediger.pl...@vodafone.com>
> > Yes, forgot to mention this. You need to set at least one option get it
> created.
> >
> >
> >
> > Regards
> >
> >
> >
> > Rüdiger
> >
> >
> >
> > Von: ryo takatsuki [mailto:ryotakats...@gmail.com]
> > Gesendet: Mittwoch, 22. Januar 2014 19:07
> > An: dev@httpd.apache.org
> > Betreff: Re: UDS support for mod_rewrite
> >
> >
> >
> > Just a las quick comment about using a <Proxy> section to define the
> proxy. I could not make it work using the below snippet:
> >
> >
> >
> >          <Proxy "unix:/path/to/some.sock|fcgi://myserver">
> >
> >          </Proxy>
> >
> >
> >
> > Digging into the code, I realized the worker was only created if more
> arguments were provided (which is not mentioned to be possible in the docs,
> or I could not find it):
> >
> >
> >
> >          <Proxy "unix:/path/to/some.sock|fcgi://myserver" timeout=300 >
> >
> >          </Proxy>
> >
> >
> >
> > Then the worker is created and I can remove my extra "ProxyPass"
> directives. Is it intended to only create the worker if we need to
> configure its settings?
> >
> >
> >
> > It makes sense but it would be a good improvement to make the worker to
> be always created if it does not exists, regardless of if some more
> settings are provided.
> >
> >
> >
> > Sorry about the offtopic and thanks a lot to  Rüdiger for the hint!
> >
> >
> >
> > 2014/1/22 ryo takatsuki <ryotakats...@gmail.com>
> >
> > >Your "hack" has the additional benefit is being
> >
> > >a pooled connection and not a one-shot, and therefore
> >
> > >will have better performance. But that isn't related
> >
> > >to UDS at all.
> >
> >
> >
> > Well, it is related to UDS in the sense of being my solution to make my
> rewrites end up serving content obtained through a Unix socket :).
> >
> >
> >
> > I initially had the old version of the UDS patch working with
> mod_rewrite (using the default forward proxy worker) but it broke with
> newer versions of the patch so I figured out that way of tricking
> mod_rewrite.
> >
> >
> >
> > Regarding using a <Proxy> section to define the workers, I see the code
> that should be defining it but I'm not able to make it work. I will
> investigate it a little further, thanks!
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Juanjo.
> >
> >
> >
> > 2014/1/22 Daniel Ruggeri <drugg...@primary.net>
> >
> > On 1/22/2014 5:48 AM, Juan José Medina Godoy wrote:
> > > Do you think that approach is safe or is it likely to break at some
> > > point? (relaying on the workers being located by url in that way,
> > > without having to provide the socket in the rewrite)
> >
> > Seems safe... and quite clever, actually.
> >
> > --
> > Daniel Ruggeri
> >
> >
> >
> >
> >
> >
> > --
> >  I've seen things you people wouldn't believe.
> > Attack ships on fire off the shoulder of Orion.
> > I watched C-beams glitter in the dark near Tannhauser Gate.
> > All those moments will be lost in time like tears in rain.
> > Time to die.
> >
> >
> >
> >
> >
> >
> > --
> >  I've seen things you people wouldn't believe.
> > Attack ships on fire off the shoulder of Orion.
> > I watched C-beams glitter in the dark near Tannhauser Gate.
> > All those moments will be lost in time like tears in rain.
> > Time to die.
> >
> >
> >
> >
> > --
> >  I've seen things you people wouldn't believe.
> > Attack ships on fire off the shoulder of Orion.
> > I watched C-beams glitter in the dark near Tannhauser Gate.
> > All those moments will be lost in time like tears in rain.
> > Time to die.
>
>


-- 
 I've seen things you people wouldn't believe.
Attack ships on fire off the shoulder of Orion.
I watched C-beams glitter in the dark near Tannhauser Gate.
All those moments will be lost in time like tears in rain.
Time to die.

Reply via email to