Kong 0.11.1 evaluation order of proxy is not clear between Prefix URI and Regex URI

[monday0rsunday]

At this time, Kong 0.11.1 say that: URI prefixes are always evaluated first , but it is not clear.

In #2899, @checky has raised that in issue 1

If I understand correctly URI prefixes are always evaluated first , following expected result should be correct:

Setting

• /some/prefix--> API 1
• /some/prefix/{regex1}/some/postfix --> API2

Expected result

• /some/prefix--> API 1
• /some/prefix/1 --> API1
• /some/prefix/1/some/postfix --> API1
• /some/prefix/1/some/postfix/1 --> API1

But actual result is

Actual result

• /some/prefix--> API 1
• /some/prefix/1 --> API1
• /some/prefix/1/some/postfix --> API2
• /some/prefix/1/some/postfix/1 --> API2

So I don't know whether it is a bug, or I mis-understand something?

[monday0rsunday]

I've found that there is a test case which describe my example

https://github.com/Kong/kong/blob/master/spec/01-unit/010-router_spec.lua#L311

So maybe it is not a bug, but the documentation is not clear, and not completed.

As far as I know, Kong have 3 rules:

1. Prefix URI evaluation is ordered by length
2. Regex URI evaluation is ordered by API creation time
3. Prefix URI are always evaluate first

But from the test case, rule 3 is not enough. Could you please add required rules?

[thibaultcha]

Hi,

There might indeed be some lack of documentation in this case. The behavior we follow is identical to that of NGINX's location block:

1. match plain prefixes by descending order of length
2. match regexes (NGINX does so in the order they are defined in the file, we do so in creation order in the database)
3. if a regex match was found in step 2, override the match from step 1

There is one crucial piece to your precise use-case that we have not yet implemented, which is the ^~ prefix of NGINX's location blocks:

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

See: https://nginx.org/en/docs/http/ngx_http_core_module.html#location

In your case, you wish to define your first two endpoints with such a rule: if one of them match, short-circuit step 2 and return the plain URI as a match.

This could indeed be clarified in the documentation, and this rule should eventually be implemented in the router as well.

[monday0rsunday]

Thank you very much for your clarification :)

[bungle]

As this stuff is now merged to docs, I will close this:
https://github.com/Kong/docs.konghq.com/pull/1432/files#diff-eec0dfe69fd07b94930ca736fff3f8b0R726

We have a lot of thoughts on this, so keeping this open is not necessary.