Ruby Forum NGINX > use different fastcgi backend in different folder

I am wondering how I can tell nginx to use a different fastcgi backend
for my phpmyadmin subfolder /pma.
This is what I did:

        location ~ /pma/.+\.php$ {
                fastcgi_pass   127.0.0.1:9001;
        }

        location ~ \.php$ {
                fastcgi_pass   127.0.0.1:9000;
        }

The php backend on port 9001 is chrooted to the /pma folder. The problem
is, that $fastcgi_script_name now contains the /pma, so the php backend
can't find the right file.
How can I strip of the /pma from $fastcgi_script_name.

I don't want to make another virtual host, since I don't want a seperate
port or subdomain just for phpmyadmin. Is a seperate vhost really the
only way to go?

Regards,
Samy

On Mon, Sep 01, 2008 at 12:57:05AM +0200, Samuel Vogel wrote:

>        }
> 
> The php backend on port 9001 is chrooted to the /pma folder. The problem 
> is, that $fastcgi_script_name now contains the /pma, so the php backend 
> can't find the right file.
> How can I strip of the /pma from $fastcgi_script_name.
> 
> I don't want to make another virtual host, since I don't want a seperate 
> port or subdomain just for phpmyadmin. Is a seperate vhost really the 
> only way to go?

Try the following:

        location ~ /pma/.+\.php$ {
                rewrite  ^/pma(/.+)$  $1  break;

                fastcgi_pass   127.0.0.1:9001;
        }

This reminds me Igor, will it ever be possible (or is there some way
it's possible now) to use matched patterns in regex location blocks?

E.g.

  location ~ ^(.*)/blah$ {
    fastcgi_param CUSTOM_VAR  $1;
  }

Cheers,
Igor

Igor Sysoev schrieb:
> Try the following:
>
>         location ~ /pma/.+\.php$ {
>                 rewrite  ^/pma(/.+)$  $1  break;
>
>                 fastcgi_pass   127.0.0.1:9001;
>         }
Thanks, this works!
Even thou it works now, maybe somebody with some spare time could
explain to me what this actually does.
I couldn't explain it to myself just with looking at the docs!

Thanks,
Samy

On Mon, Sep 01, 2008 at 09:57:47AM +0100, Igor Clark wrote:

> This reminds me Igor, will it ever be possible (or is there some way  
> it's possible now) to use matched patterns in regex location blocks?
> 
> E.g.
> 
>   location ~ ^(.*)/blah$ {
>     fastcgi_param CUSTOM_VAR  $1;
>   }

I like to use location regex captures and it will be implemented.

On Mon, Sep 01, 2008 at 02:59:58PM +0200, Samuel Vogel wrote:

> explain to me what this actually does.
> I couldn't explain it to myself just with looking at the docs!

        rewrite  ^/pma(/.+)$  $1  break;

deletes /pma/ from URI and disables ("break") looking a new location
for the new URI. Thus request uses this localtion configuration.

Igor Sysoev schrieb:
>         rewrite  ^/pma(/.+)$  $1  break;
>
> deletes /pma/ from URI and disables ("break") looking a new location
> for the new URI. Thus request uses this localtion configuration
Okay, now I get it. Thanks!

I'm not sure how familiar you are with regex but just in case and if
perhaps others are reading and it helps,

location ~ /pma/.+\.php$

~ means use regex to match the location
it starts by matching /pma/  and then .+ means one or more of any char
$ means the pattern has to end with .php
and the \. just escapes the . so it isn't  any char like above
this one has no brackets () so it doesn't capture any data

next,

rewrite  ^/pma(/.+)$  $1  break;

the ^ means matching from the start of line
the brackets () mean capture what matches inside them
in this case capture / and one ore more of any char
since the capture ends up against the $ that means capture all til the
end of line
the $1 will contain  whatever was captured in the part above
and break means stop looking if this matches

rewrite means to match the first expression and rewrite as second 
expression
so here since the second part is simply $1 it means whatever is captured
by the brackets will be the entire result of the rewrite
hence, here it is  "/ plus anything after" but drops the part not in the
capture

hope that helps... just looking to give back a wee little to the list.

Chris :)

Excellent, that will be a great addition.

Thanks,
Igor