5 ms·

My only quibble with Nginx so far is the magical order in which it evaluates location directives. http://wiki.nginx.org/HttpCoreModule#location http://wiki.ngin

My only quibble with Nginx so far is the magical order in which it evaluates location directives. http://wiki.nginx.org/HttpCoreModule#location http://wiki.nginx.org/HttpCoreModule#location On more than one occasion, you have to unintuitively try to figure out whether a rule at the bottom is getting matched before a rule at the top. The matching algo is quite intricate and easy to to trip up on. It tries to help novices by matching literal strings first for them rather than simply making a note of the performance benefits of putting literal locations at the top, but ends up failing to reveal the true matching order at a glance - you need to check the verbose logs, yuck.

harshreality 14y ago
I think the configuration language will eventually have to be reworked to address some of the issues with magical ordering and unintuitive behavior. Making the configuration language lua, for instance, would be a huge step forward, because many complex configs already use the lua 3rd party module. In addition to "location" eval order, "If" statements are another common gotcha.
mfjordvald 14y ago
I'll fully grant you that the learning curve for locations is quite steep and it takes some getting used to, but the order is always logical and it's entirely possible to reason your way through it without needing verbose logs.
- leeoniya 14y ago
  Perhaps you have not been thrown someone else's list of 15-20 locations and tried to determine why one was not matching, and what was being matched before it based on specificity, whether or not it was a literal or regex, whether or not it halted further matching in the order that specific type was defined. The complexity is entirely unneeded, mod_rewrite could def use some minor convenience tweaks, but is far more intuitive and therefore more effective in both understanding and debugging. I assure you that "match in order defined, unless passed through explicitly by a sub-condition" is sufficient and simple for 99.5%. nginx's "match literals, then match everything, then choose most specific, in the order defined by its type" is craziness, "getting used to it" does not make it good, it's simply the first unnecessary step in making it useable.
  - mfjordvald 14y ago
    I've spent about 3 years doing support in #nginx. Perhaps I've just been thrown someone else's list of 15-20 locations too many times. Locations definitely need reworking, never said they didn't, I just took issue with the having to check the verbose logs as it's perfectly possible without.
    - leeoniya 14y ago
      You don't have to if you've done it for 3 years and are familiar with nginx's "rules". Otherwise if you want to avoid wasting 3 hours, you sometimes have to. Those rules are not well defined either. What is a "literal string" / "conventional string"? Ok, "=" is clear, but what is /images/, how about /im[ag]es/, and /images/$? Since these literal strings are not quoted, what black magic is used to classify the location directive as regex or literal? I would actually love to know this, probably the biggest stumbling point for me. Especially since it uses decoded uris, because "$" could have been a "%24" in a literal string path, OR it could be a regex end of line assertion...wtf? if you can somehow understand this without having to poke the logs or through vast experience of prior trial and error, my hat's off to you, sir.
      - harshreality 14y ago
        The type of match is made explicit before the string/pattern. "location = string" and "location string" and "location ^~ string" are non-regex matches. "location ~ pattern" and "location ~* pattern" are regex matches. Matching order is unintuitive and therefore bad, and there are plenty of other quirks with nginx configs that should be made more intuitive, but confusion between regex and non-regex is unusual. It's all described right here: http://wiki.nginx.org/HttpCoreModule#location http://wiki.nginx.org/HttpCoreModule#location
        leeoniya 14y ago
        ok, read through it again. the regex distinction is clear, that was my bad. the choice of prefix symbols is pretty poor. ^~ looks related to ~ and ~*. in the docs, the regex prefixes are presented first, so i associated ~ as a regex indicator. how wrong i was. i generally disagree with ^ being the universal "not" indicator out of context since it's a "beginning of line assertion" when not preceded by "[" within a regex. The fact that it indicates what follows is a regex-halting literal string prefix match (exactly what ^ would indicate in a normal regex) is plain confusing. thanks
Vidart 14y ago
It's not a magic. It's just an optimization. Prefixed strings are organized to the radix tree for fast configuration lookup. But the only way to deal with regexps is to execute them sequentially. btw, the official doc is here: http://nginx.org/en/docs/http/ngx_http_core_module.html#location http://nginx.org/en/docs/http/ngx_http_core_module.html#loca...

harshreality 14y ago

I think the configuration language will eventually have to be reworked to address some of the issues with magical ordering and unintuitive behavior. Making the configuration language lua, for instance, would be a huge step forward, because many complex configs already use the lua 3rd party module. In addition to "location" eval order, "If" statements are another common gotcha.

mfjordvald 14y ago

I'll fully grant you that the learning curve for locations is quite steep and it takes some getting used to, but the order is always logical and it's entirely possible to reason your way through it without needing verbose logs.

leeoniya 14y ago
Perhaps you have not been thrown someone else's list of 15-20 locations and tried to determine why one was not matching, and what was being matched before it based on specificity, whether or not it was a literal or regex, whether or not it halted further matching in the order that specific type was defined. The complexity is entirely unneeded, mod_rewrite could def use some minor convenience tweaks, but is far more intuitive and therefore more effective in both understanding and debugging. I assure you that "match in order defined, unless passed through explicitly by a sub-condition" is sufficient and simple for 99.5%. nginx's "match literals, then match everything, then choose most specific, in the order defined by its type" is craziness, "getting used to it" does not make it good, it's simply the first unnecessary step in making it useable.
- mfjordvald 14y ago
  I've spent about 3 years doing support in #nginx. Perhaps I've just been thrown someone else's list of 15-20 locations too many times. Locations definitely need reworking, never said they didn't, I just took issue with the having to check the verbose logs as it's perfectly possible without.
  - leeoniya 14y ago
    You don't have to if you've done it for 3 years and are familiar with nginx's "rules". Otherwise if you want to avoid wasting 3 hours, you sometimes have to. Those rules are not well defined either. What is a "literal string" / "conventional string"? Ok, "=" is clear, but what is /images/, how about /im[ag]es/, and /images/$? Since these literal strings are not quoted, what black magic is used to classify the location directive as regex or literal? I would actually love to know this, probably the biggest stumbling point for me. Especially since it uses decoded uris, because "$" could have been a "%24" in a literal string path, OR it could be a regex end of line assertion...wtf? if you can somehow understand this without having to poke the logs or through vast experience of prior trial and error, my hat's off to you, sir.
    - harshreality 14y ago
      The type of match is made explicit before the string/pattern. "location = string" and "location string" and "location ^~ string" are non-regex matches. "location ~ pattern" and "location ~* pattern" are regex matches. Matching order is unintuitive and therefore bad, and there are plenty of other quirks with nginx configs that should be made more intuitive, but confusion between regex and non-regex is unusual. It's all described right here: http://wiki.nginx.org/HttpCoreModule#location http://wiki.nginx.org/HttpCoreModule#location
      - leeoniya 14y ago
        ok, read through it again. the regex distinction is clear, that was my bad. the choice of prefix symbols is pretty poor. ^~ looks related to ~ and ~*. in the docs, the regex prefixes are presented first, so i associated ~ as a regex indicator. how wrong i was. i generally disagree with ^ being the universal "not" indicator out of context since it's a "beginning of line assertion" when not preceded by "[" within a regex. The fact that it indicates what follows is a regex-halting literal string prefix match (exactly what ^ would indicate in a normal regex) is plain confusing. thanks

Vidart 14y ago

It's not a magic. It's just an optimization. Prefixed strings are organized to the radix tree for fast configuration lookup. But the only way to deal with regexps is to execute them sequentially. btw, the official doc is here: http://nginx.org/en/docs/http/ngx_http_core_module.html#location http://nginx.org/en/docs/http/ngx_http_core_module.html#loca...