Thanks Maxim, Well, regex location for this particular exemple is indeed useless, but might prove very useful when URI description is not trivial. Too bad they are that flawed.
I remember this talk very well indeed and think about it almost daily when dealing with nginx configuration. I had hopes for regex locations... ;o) --- *B. R.* On Wed, Nov 18, 2015 at 9:43 PM, Maxim Dounin <[email protected]> wrote: > Hello! > > On Wed, Nov 18, 2015 at 09:18:51PM +0100, B.R. wrote: > > > WIth the following configuration: > > server { > > listen 80; > > listen [::]:80; > > > > location / { > > location ~* "^/[[:alnum:]]+$" { > > default_type text/plain; > > return 200 "KO"; > > } > > } > > > > location ~* "^/test" { > > default_type text/plain; > > return 200 "OK"; > > } > > } > > > > I noticed that calling example.org/test returns KO. > > > > The location docs > > <http://nginx.org/en/docs/http/ngx_http_core_module.html#location> say > the > > longest prefix match ('/') is remembered then regex are checked. Since > the > > 'test' regex is on the same level, you would expect higher precedence for > > it compared to the embedded 'alnum' one, which is one level deeper. > > When using nested locations within the location "/" (the longest > prefix location found at top level) nginx will repeat location > search: it will search for a longest prefix location (won't find > anything as there are no prefix locations within "/"), and then > will search for regex locations (will find one with "alnum"). As > a regex location was found, searching stops. > > > If secondary-level regex locations have the same priority as others, you > > are basically doomed trying to prioritize regex locations between each > > others using prefix locations at an upper-level. > > Things are not that bad, as only locations within the longest > prefix location are considered. And, actually, when using regex > locations you are doomed anyway. > > Here is Igor's talk about configuration scalability, in particular > he talks about regex locations and why it's better to avoid them > (I believe you've been there, actually): > > http://www.youtube.com/watch?v=YWRYbLKsS0I > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
