Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

There is currently a block of one location /

  location / {
    root  /var/www/docs;
    proxy_pass  http://backend;
    proxy_buffering     on;
    proxy_buffer_size   64k;
    proxy_buffers       256   64k;
  }

that needs to be filtered by IP.

Ideally, in order to reduce the number of repetitions of the same directives in location, I would like to perform the test within the location block

  location / {

    if ($uri ~ '^/(abc|def|ghi)') {
        allow 10.0.0.0/8;
        allow 1.2.3.4;
        deny all;
    }

    root  /var/www/docs;
    proxy_pass  http://backend;
    proxy_buffering     on;
    proxy_buffer_size   64k;
    proxy_buffers       256   64k;
  }

Unfortunately, it seems the allow/deny directives cannot be used within a if block.

"allow" directive is not allowed here in /etc/nginx/sites-enabled/mysite:20

Is there an elegant way to perform the test without repeating the location blocks?

(like

  location ~ /(abc|def|ghi) {

        allow 10.0.0.0/8;
        allow 1.2.3.4;
        deny all;

        ... 5 other lines root,proxy...
   }

  location  / {

        ... 5 other lines root,proxy...
   }

)

share|improve this question

3 Answers 3

up vote 0 down vote accepted

Like coredump said, no, use multiple locations.

But it is possible to make the contents of the location blocks less repetitive. The key here is a named location block which contains the root and proxy_... directives.

For example:

location / {
  try_files $uri @proxy;
}
location ~ /(abc|def|ghi) {
  allow 10.0.0.0/8;
  allow 1.2.3.4;
  deny all;

  try_files $uri @proxy;
}
location @proxy {
  root  /var/www/docs;
  proxy_pass  http://backend;
  proxy_buffering     on;
  proxy_buffer_size   64k;
  proxy_buffers       256   64k;
}

And probably even better would be to place the root directive outside all the location blocks.

share|improve this answer

No. Use multiple locations, it may look ugly but you will end with less chance of if craziness.

Also remember that nginx processes first the regex matches and if none matches it tries the most specific literal location, being location / kind of a catch all location. Knowing that you can maybe diminish the number of locations you need. Take a look at this doc to see how requests are processed.

share|improve this answer
    
Thanks. The if craziness looks like a nginx bug... Repeating the location directives ad nauseum for each case is contrary to the most elementary programming concepts. But it sounds like there no choice :-( –  ring0 Apr 1 '11 at 3:42
    
Remember that nginx is a web server not a programming language :) On apache you would end with something close :) –  coredump Apr 1 '11 at 3:55
    
I studied a bit the code of nginx, as it is a performance example. One thing I liked about nginx, is that it stands pretty far from apache... I don't think there (should be) is a separation between programming languages and configuration scripts. Unfortunately, long time existing tools like apache seem to show the way. –  ring0 Apr 1 '11 at 4:13
    
@ring I don't know, I like that you could not do what you wanted. It would be easier, but it would be harder to read and it could get very messy in some cases (not yours, but allowing it would open the doors to hell :)) –  coredump Apr 1 '11 at 4:15

Usually in such cases can help "nested locations" ...

location / {
   root /var/www/docs;
   allow all;

   location /admin {
       deny 1.2.3.4;
   }

}

... but not all directives inherited in nested locations. Sadly, but exactly proxy_pass, fastcgi_pass and similar are not inherited... So solution proposed earlier (with @namedlocation) is correct in this case. You can also use a directive include for "proxy_pass block", of course.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.