Hi there,

Yes, all that was /very/ helpful, thank you!!!

Much appreciated,

Jore


On 4/6/23 10:09 am, Maxim Dounin wrote:
> The most important part is in the following paragraph:
> A location can either be defined by a prefix string, or by a
> regular expression. Regular expressions are specified with the
> preceding “~*” modifier (for case-insensitive matching), or the
> “~” modifier (for case-sensitive matching). To find location
> matching a given request, nginx first checks locations defined
> using the prefix strings (prefix locations). Among them, the
> location with the longest matching prefix is selected and
> remembered. Then regular expressions are checked, in the order of
> their appearance in the configuration file. The search of regular
> expressions terminates on the first match, and the corresponding
> configuration is used. If no match with a regular expression is
> found then the configuration of the prefix location remembered
> earlier is used.
>
> In other words:
>
> - Regular expressions are with "~*" and "~" modifiers. Everything
> else are prefix strings.
>
> - For prefix strings, longest matching prefix is used (note that
> order of prefix locations is not important).
>
> - If the longest prefix found does not disable regular expression
> matching (with the "^~" modifier, as per the quote you've
> provided), regular expressions are checked in order.
>
> As long as a regular expression is matched, nginx will use the
> corresponding location. If no regular expressions matched, nginx
> will use the longest matching prefix location.
>
> The "location" directive description additionally provides some
> examples explaining how this all works. Reading the
> https://nginx.org/en/docs/http/request_processing.html article
> might be also helpful.
>
>> 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. ;)
> In your configuration,
>
> location ^~ "/browser/.*/welcome/welcome.html" { ... }
>
> is a location defined by a prefix string.
>
> It will work for requests with the given prefix, such as
> "/browser/.*/welcome/welcome.html" or
> "/browser/.*/welcome/welcome.html.foobar". But since it is a
> prefix string, and not a regular expression, the ".*" characters
> do not have any special meaning, and matched literally. That
> is, this location won't match requests to resources like
> "/browser/foo123/welcome/welcome.html", since these use a
> different prefix.
>
> To make it match requests to
> "/browser/foo123/welcome/welcome.html", you have to change the
> location to a location defined by a regular expression. That, you
> have to change the "^~" modifier to "~" modifier (and it is also a
> good idea to change the regular expression to a slightly more
> explicit one, see my initial response). But it is not enough, see
> below.
>
> Similarly,
>
> location ^~ /browser { ... }
>
> is also a location defined by a prefix string. Further, due to
> the "^~" modifier, it disables matching of regular expressions, so
> any request which starts with "/browser" won't be checked against
> regular expressions. So you have to remove the "^~" modifier if
> you want nginx to check regular expressions, notably the one in
> the first location (assuming "^~" is changed to "~").
>
> Hope this helps.
>_______________________________________________
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx