# Location ^~ modifier **URL:** \ **Category:** NGINX\ **Created:** [December 7, 2015, 10:10pm UTC](https://www.ruby-forum.com/t/location-modifier/243591 "2015-12-07T22:10:13Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Rafa\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/958977/32.png) [@Rafa\_F](https://www.ruby-forum.com/u/Rafa_F)\ **Post date:** [December 7, 2015, 10:10pm UTC](https://www.ruby-forum.com/t/location-modifier/243591/1 "2015-12-07T22:10:13Z")
Hello, I got kind of a newbie question: Does the ^~ location modifier finds a matching string at the start of an URI? I naively thought it was just a variant of the classic prefix search, without any constraint on the placement of the matched string in an URI. Is there a simple way of matching the longest prefix location anywhere in an URI, discarding any regex location at the same level? ## ​Thanks,​ _B. R._ ---
**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\ **Post date:** [December 8, 2015, 9:41am UTC](https://www.ruby-forum.com/t/location-modifier/243591/2 "2015-12-08T09:41:17Z")
On Mon, Dec 07, 2015 at 10:08:40PM +0100, B.R. wrote: Hi there, > Does the ^~ location modifier finds a matching string at the start of an > URI? Yes. > I naively thought it was just a variant of the classic prefix search, Yes. > without any constraint on the placement of the matched string in an URI. No. > Is there a simple way of matching the longest prefix location anywhere in > an URI, discarding any regex location at the same level? “prefix” means “at the start”. I’m not sure what you’re asking. The first regex location that matches is used (with caveats). So if you have a regex location which is just your desired string, that is first in the config file, then it will be used ahead of any other regex locations that might have been used. ## f Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\ **Post date:** [December 8, 2015, 6:35pm UTC](https://www.ruby-forum.com/t/location-modifier/243591/3 "2015-12-08T18:35:12Z")
The location [http://nginx.org/en/docs/http/ngx\_http\_core\_module.html#location](http://nginx.org/en/docs/http/ngx_http_core_module.html#location) documentation states the following: _A location can either be defined by a prefix string, or by a regular expression._ Thus, ~ and ~\* being regex modifiers, the rest is considered as being classified as 'prefix. That means the following is a ‘prefix’ location block: location /whatever/ { } That said, this block will match the /whatever/ string anywhere in the URI string, not only at its start. As a consequence, to me, the meaning of ‘prefix’ was not tied to the location of the matched string in the URI, but rather a definition more like ‘matching a string in the URI’. Without any modifier, a prefix location will be sensitive to the presence of regex locations, while with the ^~ modifier it also won’t match the same cases. That modifier actually have 2 consequences, instead of only the first being documented. My brain hurts… Note that if you remove the capability of the default (without any modifier) location to match the string anywhere in the URI (thus becoming ‘prefix’ _per se_), you do not have any other means to match a string regardless of its position in the URI than regex ones… which are discouraged from being used (see recent answer from Maxim on a similar topic). ## ​Where is the exit of the maze again?​ _B. R._ ---
**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\ **Post date:** [December 9, 2015, 9:47am UTC](https://www.ruby-forum.com/t/location-modifier/243591/4 "2015-12-09T09:47:39Z")
On Tue, Dec 08, 2015 at 06:33:52PM +0100, B.R. wrote: Hi there, > That means the following is a ‘prefix’ location block: > location /whatever/ { > } > > That said, this block will match the /whatever/ string anywhere in the URI > string, not only at its start. No, it won’t. === location / { return 200 “in location /\n”; } ``` location /aaa/ { return 200 "in location /aaa/\n"; } ``` === $ curl [http://localhost/aaa/bbb/](http://localhost/aaa/bbb/) in location /aaa/ $ curl [http://localhost/bbb/aaa/](http://localhost/bbb/aaa/) in location / > As a consequence, to me, the meaning of ‘prefix’ was not tied to the > location of the matched string in the URI, but rather a definition more > like ‘matching a string in the URI’. No. “prefix” has its normal English language meaning. The documentation at [Module ngx\_http\_core\_module](http://nginx.org/r/location) is correct. (I think the documentation there is _incomplete_, as it is not immediately clear to me how nested locations are searched. But that has been clarified on the mailing list recently, and that clarification matches what can be seen in tests.) > Where is the exit of the maze again? prefix matches – without modifier, with modifier ^~, and (technically, probably) with modifier = – are exact string matches at the start of the url. (And consequently should all start with the character “/”.) If you want to match something that is not an exact string match at the start of the url, you must use something that is not a prefix match. ## f Francis D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![B.R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@B.R](https://www.ruby-forum.com/u/B.R)\ **Post date:** [December 9, 2015, 8:51pm UTC](https://www.ruby-forum.com/t/location-modifier/243591/5 "2015-12-09T20:51:17Z")
Thanks Francis, I directly went back to the basics nginx 101 lesson. I feel dumb all of a sudden… ## The maze was made of my misconceptions! I wonder where they came from. I was sure I tested what I said… which is impossible. _B. R._