Yeppers... The key thing to remember that it was only
pre-existing workers (ie: those defined) that could
be associated with UDS, and so if you could "trick"
mod_rewrite (or anyone else) to use that worker, you
were golden.
The problem was the mod_rewrite, in general, would use
the generic reverse proxy worker, and so I needed to
add code that would see if rewrite had forced a proxy:
and then adjust that generic worker accordingly.
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.
On Jan 22, 2014, at 6:48 AM, Juan José Medina Godoy <ryotakats...@gmail.com>
wrote:
> Cool :).
>
> As a workaround for that limitation I was using a "hack" (in case someone
> finds it useful):
>
> ProxyPass /mybackend-fpm-proxy !
> ProxyPass /mybackend-fpm-proxy unix:/path/to/www.sock|fcgi://mybackend-fpm/
> ...
> RewriteRule ^(.*\.php(/.*)?)$ fcgi://mybackend-fpm/%{REQUEST_FILENAME} [P,L]
> ...
>
> As the workers are find by url, I can omit the socket it the rewrite, but I'm
> forced to define them using a ProxyPass. As I'm not interested in mapping an
> url to the proxy, I disable it (with the ! part), which looks really ugly :).
>
> 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)
>
> Best regards,
>
> Juanjo.
>
>
>
> 2014/1/21 Jim Jagielski <j...@jagunet.com>
> FWIW, I'm looking into adding UDS support for mod_rewrite (et.al.)
> by making the generic default reverse proxy worker UDS aware.
>
