Proxy pass location inheritance

[Brian Hill]

So there is no precedence given to nested regex locations at all? What value does nesting provide then?

This seems like it should be a fairly simple thing to do. Image/CSS requests to some folders get handled one way, and image/CSS requests to all other folders get handled another way. This is an experimental pilot project for a datacenter conversion, and the use of regex to specify both the file types and folder names is mandatory. The project this pilot is for will eventually require more than 50 server blocks with hundreds of locations in each block if regex cannot be used. It would be an unmaintainable mess without regex. 

Am I missing something here? Is NGINX the wrong solution for what I'm trying to accomplish? Is there another way to pull this off entirely within NGINX, or should I be using NGINX in conjunction with something like HAProxy to route those particular folders where they need to go (i.e., catch and proxy the .Net folder requests in HAProxy, and pass everything else along to NGINX?) I was hoping to avoid the use of HAProxy and handle everything directly within NGINX for the sake of simplicity, but it's sounding like that may not be an option. 



________________________________________
From: nginx-bounces at nginx.org [nginx-bounces at nginx.org] on behalf of Maxim Dounin [mdounin at mdounin.ru]
Sent: Monday, February 17, 2014 9:30 AM
To: nginx at nginx.org
Subject: Re: Proxy pass location inheritance

Hello!

On Mon, Feb 17, 2014 at 05:15:45PM +0000, Brian Hill wrote:

> So it sounds like my only solution is to restructure the locations to avoid the original match in /. I don't have access to the servers again until tomorrow, but I'm wondering if something like this would work:
>
> location / {
>           #base content
>   }
>
> location ~ regex2 {
>           #alternate folders to proxy_pass from .Net servers
>  }
>
> location ~ regex3 {
>           #catch all css, js, images, and other static files
>
>           location ~ regex4 {
>                     #same as regex2. Alternate static location for .Net apps
>           }
>           location / {
>                      #match all "static files" not caught by regex4
>           }
> }

This is certainly now how configs should be written, and this
won't work as regex4 will never match (and nested / will
complain during configuration parsing, but it doesn't make sense
at all).

> If I'm understanding location precedence correctly, the regex3
> location should always hit first, because its regex will contain
> an exact match for the file types. The nested regex4 (identical
> to regex2) will then match the folder name in that request, so
> the custom configuration can be applied only to the regex3 file
> types contained within the regex4 folders. Requests for the
> regex3 file types at locations not matching regex4 will be
> handled by the nested /.
>
> Will this work, or will the second nested / location break things?

Try reading http://nginx.org/r/location again, and experimenting
with trival configs to see how it works.

Try to avoid using regular expressions by all means at least till
you'll understand how it works.  It's very easy to do things wrong
using regular expressions.

--
Maxim Dounin
http://nginx.org/

_______________________________________________
nginx mailing list
nginx at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx