Kong: Routes uniqueness & request path proxying

[kwahome]

Summary

With the new services and routes model, uniqueness is enforced on the services table where name should be unique (services postgres migration). However on the routes table there is no unique field (or fields) (routes postgres migration) thus making it possible to configure a route with the same values.

This introduces two issues:

1. Duplication of routes where a route with the same values and referencing the same service can be configured
2. Configuring routes with the same values (path, methods, protocols) but referencing different services

Assuming routing by request paths, if two routes are created with the same path but referencing different services, to which service will the routing/proxying happen? As things stand, it's unclear to me as to how the proxying happens hence I'm inclined to conclude this might be a bug

Steps To Reproduce

1. Configure two services with different hosts
2. Configure two routes each pointing to each of the services above but with the same path and method
3. Access the configured route

What is the intended/desired proxying behaviour?

Additional Details & Logs

• Kong version (0.13.0)

[thibaultcha]

Hi,

Thanks for the feedback.

Enforcing the uniqueness of the matching rules was not supported with APIs, and it isn't with Routes either. At this point, we are thinking about implementing it, but not entirely convinced it is worth the effort: it is tricky to implement and it would reduce flexibility that one _may_ desire, such as temporarily redirecting traffic for example.
Nginx itself won't warn you if you shadow other location blocks. In the context of Kong, you can argue that it isn't fair for us to have the same expectations from our users (that they will carefully configure their Routes), because Nginx is configured in a configuration file we can browse and edit, and Kong is configured via a web API, which is harder to browse for duplicates. It also offers more matching rules than Nginx. But nonetheless, as of today, we expect careful configuration from our users. Our plans for supporting declarative configuration should help reducing the configuration errors and potential for mistakes as well.
This should answer both of your points (1. and 2.).

Concerning your question:

Assuming routing by request paths, if two routes are created with the same path but referencing different services, to which service will the routing/proxying happen?

This is a case of "tias", but what _should_ happen is that the Route with the highest regex_priority (or created first if there is a tie) should be selected by the Router. This is the current intended _and_ desired behavior.
That should answer your "steps to reproduce" section as well.

Since this is currently the intended design, and I have explained the rationale behind it, at this point, I think the following steps are appropriate:

1. Closing this issue since we do not consider it a bug
2. If you want to, proposing a PR to detect Route shadowing
3. Wait for an _eventual_ Route shadowing detection added by us or another contributor

For now, I will leave this open a little longer for this conversation to continue.

[bungle]

I remember that we discussed about this, but I think we concluded that as user error. The routing is though well defined here (it is not unknown what gets picked).

[mwaaas]

@thibaultcha @bungle
What about if the name field is added back in the routes.

In the previous version of Apis, path uniqueness was not enforced either.
But we were using name to make sure they were enforced. in our case, the name was a generated by a concatenation of path and methods. And by this, we ensured that we won't have Apis with the same path.

[mwaaas]

@thibaultcha
what about having all those fields that determine proxying to have a constraint of unique together.

[thibaultcha]

what about having all those fields that determine proxying to have a constraint of unique together.

This is the desired implementation goal, but we have much higher priority items and are unlikely to get to it anytime soon. Some work has been done in the Enterprise Edition, we might consider porting it to the Community Edition someday, but again, priority is quite low here...

Closing this and considering the question answered now. Thanks.

[ibzip]

This behavior should be clearly documented in the documentation to make it easier for the user!

[thibaultcha]

@ibzip It’d be great to receive a documentation Pull Request clarifying this point!