The location directive

[Maxim Dounin]

Hello!

On Thu, Apr 07, 2011 at 08:47:10PM +0200, Thomas Love wrote:

> Hello list
> 
> I am new to nginx. I put it into production a couple of weeks ago, and I
> have been very pleased with its efficiency and stability. But I have
> been wondering about an aspect of the location directive. The only previous
> discussion I have found of this went dead without resolution (
> http://forum.nginx.org/read.php?2,4225)

There were lots of such discussions, and the only expected answer 
to all proposals to add global/continue/whatever locations which 
alter configuration is: no.

The reason is simple: with large config it's practically 
impossible to find out how requests will be processed when 
such "global" locations are present.

> By way of illustration, this motif was my first attempt at a configuration,
> and I suspect -- assuming I am not unusually dense -- that others coming
> from Apache will have tried it too:
> 
> server {
>         listen          80;
>         root            /www/;
> 
> location ~ \.php$  {
>                 fastcgi_pass    unix:php.sock;
> }
> 
>         location ~* \.(ico|flv|swf|jpg|jpeg|png|gif|js|css|wav)$ {
>                 expires max;
>         }
> 
>         location /secrets/  {
>           auth_basic            "Restricted";
>           auth_basic_user_file  /path/to/.htpasswd;
>         }
> 
>         location /local-secrets/ {
>           allow 127.0.0.1;
>           deny all;
>         }
> }
> 
> ...and I'm aware that it's dangerously wrong. Compounding this is the fact
> that it looks - to me at least - intuitively correct. Perhaps I expected the
> location parser to be more promiscuous. The second problem is my solution:
> 
> server {
>         listen          80;
>         root            /www/;
> 
> location ~ \.php$  {
>                 fastcgi_pass    unix:php.sock;
> }
> 
>         location ~* \.(ico|flv|swf|jpg|jpeg|png|gif|js|css|wav)$ {
>                 expires max;
>         }
> 
>         location ^~ /secrets/  {
>           auth_basic            "Restricted";
>           auth_basic_user_file  /path/to/.htpasswd;
>   location ~ \.php$  {
>                 fastcgi_pass    unix:php.sock;
>   }
>           location ~* \.(ico|flv|swf|jpg|jpeg|png|gif|js|css|wav)$ {
>                 expires max;
>           }
>         }
> 
>         location ^~ /local-secrets/ {
>           allow 127.0.0.1;
>           deny all;
>   location ~ \.php$  {
>                 fastcgi_pass    unix:php.sock;
>   }
>           location ~* \.(ico|flv|swf|jpg|jpeg|png|gif|js|css|wav)$ {
>                 expires max;
>           }
>         }
> }
> 
> ...which is unwieldy, at the least. Is it correct? Is it optimal? Is it wise
> to nest these locations? (Would it get more bloated not to?)

Yes, it's correct.

I would also recommend wrapping your regular regexp locations into 
location / {} block, i.e.

    location / {
        ...

        location ~ \.php$ {
            ...
        }
    }

    location /protected/ {
        auth_basic ...

        location ~ \.php$ {
            ...
        }
    }

(ideally there should be no regexp locations at all, but I clearly 
understand that it's mostly impossible when php involved)

> My main question is -- assuming that the answers to the above are yes -- is
> there a configuration available or planned that's as simple as this:
> 
> server {
>         listen          80;
>         root            /www/;
> 
> *location continue* ~ \.php$  {
>                 fastcgi_pass    unix:php.sock;
> }
> 
>         *location continue* ~* \.(ico|flv|swf|jpg|jpeg|png|gif|js|css|wav)$
> {
>                 expires max;
>         }
> 
>         location /public-secrets/  {
>           auth_basic            "Restricted";
>           auth_basic_user_file  /path/to/.htpasswd;
>         }
> 
>         location /private-secrets/ {
>           allow 127.0.0.1;
>           deny all;
>         }
> }
> 
> By "location continue" I mean the parser to continue matching (sibling)
> locations after a positive match on those expressions. The order of matching
> would be the same. Is this / will this be possible?

No, see above.

Maxim Dounin