Hi there,

Thanks for getting back.

On 4/6/23 3:16 am, Maxim Dounin wrote:

> Hello!

[…]

> The "^~" location modifier is for prefix-match locations to prevent
> further checking of regular expressions, see
> http://nginx.org/r/location for details. If you want to use a regular
> expression, you have to use the "~" modifier instead.

Thank you for that. Apologies, I should’ve mentioned that I did review
that documentation on how nginx selects a location. Unfortunately I
didn’t find it particularly clear or helpful.

I especially thought this rule in question would match and take
precedence over the latter /browser rule, because of this line on that page:

"If the longest matching prefix location has the “^~” modifier then
regular expressions are not checked."

i.e. because this rule in question comes first and it is longer than the
latter /browser rule, a match would occur here and not later (because
processing stops here)?

And because I couldn’t find much on how nginx handles regex, I ended up
checking this question/answer
https://stackoverflow.com/questions/59846238 on Stackoverflow. It
cleared things up a little, but still made me wonder why my approach
didn’t work.

Nevertheless, your suggestions to remove the priority prefix |^~| for
the second rule fixed the problem, but I still wonder why my approach
didn’t work. ;)

Speaking of Stackoverflow, I ended up asking the question there also
https://stackoverflow.com/questions/76396334. Not to take this
conversation away from this list, but since your answer was helpful,
feel free to chime in there too if you’re looking for some upvotes :)

Thanks,
Jore

​_______________________________________________
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx