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@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx