"root" directive weirdness

Hi,
I’m trying to configure a vhost where in the default case I want it to
get
the files from /opt/nginx/html but when the uri starts with “/users/” I
want to to deliver the files from /web/users/ instead:

     location / {
         root   /opt/nginx/html;
         index  index.html index.htm;
     }

     location ~* ^/users/ {
         root   /web/users;
         rewrite ^/users(/.*) $1 last;
     }

The problem is that when I access “/users/index.html” the second
location
matches and the rewrite rule gets applied but the “root” directive is
ignored and instead the one from the first location section is applied
resulting in the delivery of the file “/opt/nginx/html/index.html”.
Am I getting something wrong about the location/root directives or is
this
a problem with nginx?

Regards,
Dennis

Hi,

Cliff W. wrote:

     }

     location ~* ^/users/ {
         root   /web/users;
         rewrite ^/users(/.*) $1 last;
     }

The reason why you’re having problems is the ‘last’ tag on the rewrite,
which will end the rewrite rules and then look for the corresponding URL
(which sends it back to the first location). Using ‘break’ instead
would prevent this, and do as you expect. However, for this situation,
the second regex is an unnecessary waste of processing.

Cliff’s solution is better :

but using

location ^~ /users/ {
root /web;
}

is more efficient than using

location /users {
root /web;
}

if you have any other location directives (especially regex ones) - see
http://wiki.nginx.org/NginxHttpCoreModule#location to find out why.

Also, if you don’t have the final / on the location (i.e. /users/
instead of /users), you may get unwanted matching urls (e.g.
/usersfiles) - depending on your URL hierarchy.

Marcus.

On Thu, 2010-01-21 at 22:10 +0100, Dennis J. wrote:

     location ~* ^/users/ {
         root   /web/users;
         rewrite ^/users(/.*) $1 last;
     }

location / {
root /opt/nginx/html;
index index.html index.htm;
}

location /users {
root /web;
}

Cliff


http://www.google.com/search?q=vonage+sucks

On Fri, 2010-01-22 at 02:45 +0200, Marcus C. wrote:

root /web;

}

That’s not true. The regex is less efficient.

Regards,
Cliff

Cliff W. wrote:

is more efficient than using

location /users {
root /web;
}

That’s not true. The regex is less efficient.

It’s not a regex (regexes are indicated by ~*). It’s a test for the URL
beginning with the represented string. If found, it does not test any
regexes. Using just

location /users

will test regexes before returning the /users location if no regexes
match.

Marcus.

Cliff W. wrote:

but using

will test regexes before returning the /users location if no regexes match.

I stand corrected. I should have read the documentation you so
thoughtfully linked to =)

:slight_smile:

I’m actually not a huge fan of the ^~ syntax. I think it’s confusing,
because it does more closely resemble the regex syntax than a static
one. I suspect that a lot of people don’t use it because of this,
thinking that it will be less efficient when in fact it is more so.

I think ^= would be less confusing, or even just plain ^, but I doubt
that it’ll get changed.

Cheers,

Marcus.

On Fri, 2010-01-22 at 05:15 +0200, Marcus C. wrote:

It’s not a regex (regexes are indicated by ~*). It’s a test for the URL
beginning with the represented string. If found, it does not test any
regexes. Using just

location /users

will test regexes before returning the /users location if no regexes match.

I stand corrected. I should have read the documentation you so
thoughtfully linked to =)

Regards,
Cliff

On 01/22/2010 01:45 AM, Marcus C. wrote:

root /opt/nginx/html;
prevent this, and do as you expect. However, for this situation, the
second regex is an unnecessary waste of processing.

Once the server configuration is complete it will be much more complex
than
the one above. That was only a simplified example to illustrate the
problem. I didn’t now that a “last” would send nginx back to the
location
stage of processing. With that in mind the processing makes sense of
course. Thanks for the explanation!

Regards,
Dennis

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs