Different FastCGI backend for /subdir: regex not matching

Maxim Dounin mdounin at mdounin.ru
Thu Aug 11 10:46:06 UTC 2011


On Thu, Aug 11, 2011 at 04:22:52AM -0400, hugo wrote:

> I have a virtual host, and for a certain subdirectory I want to use
> another fastcgi backend.
> What I have now goes something like:
> (...)
>        location ~ /subdir/ {

Do you actually want to match prefix here, as opposed to any uri 
containing "/subdir/" in it?  If yes, use

         location /subdir/ {

instead.  To prevent all other regexp locations from matching 
under /subdir/ (even if there are no regexp locations in subdir 
matched) you may also want to use "^~" (no regexp check on match), 

         location ^~ /subdir/ {

>                alias /var/www/otheraccount/public_html/;
>                 # PHP FastCGI
>                 location ^~ /subdir\/(.+)\.php {

"^~" means "no regexp check on match", you have to use "~" (regexp 
location) here instead.  And unless you really need captures here 
for some reason not present in posted config, it's enough to just 
use \.php pattern here.  You may also need "$" anchor to make sure 
you are matching extension but not some intermediate part of 

I.e. use

                  location ~ \.php$ {

here instead.

>                         return 504;
>                         include /usr/pkg/etc/nginx/fastcgi_params;
>                         fastcgi_pass;
>                         fastcgi_index index.php;
>                         fastcgi_param SCRIPT_FILENAME
> /var/www/othervhost/public_html$fastcgi_script_name;
>                         try_files $uri =502;
>                 }
>        }
>         # PHP FastCGI
>         location ~ \.php {

The same as above: you probably need "$" anchor here.

          location ~ \.php$ {

>                 include /usr/pkg/etc/nginx/fastcgi_params;
>                 fastcgi_pass;
>                 fastcgi_index index.php;
>                 fastcgi_param SCRIPT_FILENAME
> /var/www/blah/public_html$fastcgi_script_name;
>                 try_files $uri =403;
>         }
> }
> Ignore the try_files and bogus return, they're in place to try to trace
> what's happening where.
> This is nginx 1.0.4, if it matters.
> Basically, the problem is that the last try_files is triggered (I get a
> 403 requesting /subdir/index.php, and if I change that last try_files to
> 404 then I get a 404); Therefore I conclude the regex trying to catch
> php files under /subdir is not effective.

See above.  The problem is that you don't have regexp but static 
string, due to "^~" used.

> What would the proper regex be ? 
> I want it to catch /subdir/*.php, /subdir/subsub/*.php,
> /subdir/s/u/b.php, etc

Recommended pattern is:

    location / {

        location ~ \.php$ {

    location /subdir/ {

        location ~ \.php$ {

Note all top-level locations are just normal static strings with 
prefix match (most specific match wins).  Regexp locations are 
properly isolated in them, and don't interfere with processing of 
requests in other locations.

> On a related note, trying to access www.vhost.local/subdir (no trailing
> /) results in nginx trying to serve subdir from the original root (ie
> the alias isn't picked up); It may be a trivial question but I've run

This is because "/subdir" isn't matched by "location /subdir/" 
(neither by "location ~ /subdir/"), and hence it's processed in 
some other matching location (usually "location /", or implicit 
location if you don't have one defined).

> into this in the past. What is the correct way to catch both /subdir and
> /subdir/ requests?

I would recommend using something like

    location = /subdir {
        root ...
        # or just immediate redirect to /subdir/, e.g
        # return 301 /subdir/;

    location /subdir/ {
        root ...

Note that if you use 

    location /subdir/ {
        proxy_pass ...

nginx will automagically recognize that requests to "/subdir" 
should be redirected to "/subdir/", and you don't need extra 
"location = /subdir".  This applies only to locations fully 
handled by backend modules though.

> I would very much appreciate a reply on this subject, as I've been
> struggling with this for hours. Regexes are not my strong point.

Don't use regexp unless you really need to, use normal locations.
(This applies even if one have no problems with regexps.)

Maxim Dounin

More information about the nginx mailing list