<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi there,</p>
<p>Yes, all that was <i>very</i> helpful, thank you!!!</p>
<p>Much appreciated,</p>
<p>Jore</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 4/6/23 10:09 am, Maxim Dounin wrote:<br>
</div>
<blockquote type="cite" cite="mid:ZHvWHP78ch48kTM4@mdounin.ru">The
most important part is in the following paragraph:
<pre class="moz-quote-pre" wrap="">
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
<a class="moz-txt-link-freetext" href="https://nginx.org/en/docs/http/request_processing.html">https://nginx.org/en/docs/http/request_processing.html</a> article
might be also helpful.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">And because I couldn’t find much on how nginx handles regex, I ended up
checking this question/answer
<a class="moz-txt-link-rfc2396E" href="https://stackoverflow.com/questions/59846238"><https://stackoverflow.com/questions/59846238></a> 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. ;)
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.
</pre>
</blockquote>
</body>
</html>