Multiple paths & hosts per API.

[sonicaghi]

With regex support. See #192 for more details.

[thibaultcha]

• Support for regex
• Support for priority between multiple paths

[dvh]

+1. Any progress? Can't find it in the roadmap yet... I think this conflicts a bit with the ACL issue that consumers are not related to a single API but have access to all APIs. However, all APIs should have a different host, making that thought quite strange imho ;-)

[ahmadnassri]

+1 multiple host matching is certainly needed

[Malet]

👍

[frascuchon]

+1

[alexanderyoung]

+1, this is a roadblock for my use case too.

[subnetmarco]

The proposed solution would be to support the following properties on the API object:

• request_hosts (instead of request_host)
• request_paths (instead of request_path)

Both would support a list of values, and both would support named parameters with regex support, like: api.$environment(staging|production).helloworld.com or /accounts/$user/invoices/$invoice_id(\d+)/.

We still need to find a consensus on the format of the named parameter. The above format works well when the parameter is delimited by slashes / or dots ., but it wouldn't work well if there isn't any specific ending pattern, like api.$environmentservice.com (we don't know if the parameter ends at $environment or $environmentservice, so maybe something with explicit beginning and ending like api.{environment}service.com would work better (or api.{environment(\d+)}service.com).

Thoughts?

[leozc]

Thanks, @thefosk, I suggest just use a simple pattern to indicate the boundary of regex, {} may work well.

For example
{REGEX}service.com where regex can be the regular expression.

NOTE: {} may collide with {min,max} in regex, but if your parser is greedy and extract the longest pattern between {} that should not be a problem.

[supagroova]

👍

[nickmchardy]

👍

[noamelf]

👍

[tjsousa]

👍

[RossJayJones]

+1

[rsbarata]

👍

[JingWZ]

👍
eager for this. Any progress on it?

[pochadri]

+1

[kylegato]

+1

[Marak]

I'm helping setup Kong for a major enterprise and we are somewhat dependent on this feature.

If you'd like any additional resources for performing acceptance testing on v0.10.0 when it's ready please let us know.

[thibaultcha]

If you'd like any additional resources for performing acceptance testing on v0.10.0 when it's ready please let us know.

@Marak I would love to hear more about what would be those requirements indeed.

[Marak]

@thibaultcha -

One of our Senior Developers submitted the enterprise sales form a couple of times this month with no response.

We are looking to host APIs for multiple applications in one Kong. Without the ability to enter the same request_path or request_host twice, it seems fairly difficult to setup a streamlined solution. Not 100% sure I'm responding to the correct issue here.

For example, we can't figure out how to easily do something like:

1. 
request_host: marak.com
request_path: /foo

2. 
request_host: larry.com
request_path: /foo

This fails in Kong Dashboard with already exists with value /foobar, is that expected?

If so, it seems impossible to setup granular routes in Kong for multiple applications which share the same routing namespaces.

[thibaultcha]

@Marak In that particular case you described, wouldn't setting those 2 different APIs work with:

1. 
request_host: marak.com

2. 
request_host: larry.com

There doesn't seem to be a need for request_path here?

[Marak]

Why would you assume there is no need for request_path?

I'll try to make it more clear:

1. 
request_host: marak.com
request_path: /foo
upstream_url: http://google.com/foo

2. 
request_host: marak.com
request_path: /foobar
upstream_url: http://bing.com/foo

3. 
request_host: larry.com
request_path: /foo
upstream_url: http://yahoo.com/foo

4.
request_host: larry.com
request_path: /foobar
upstream_url: http://altavista.com/foo

[thibaultcha]

There was no assumption but a clear indication that in that particular example you have, there was no need for it; surely it had to be more than that :)

Yes, that use case in the second example is covered in the upcoming new router.

[vautrinr]

Hello!

I would like to know, when it could be available??

Rémi 👍

[Marak]

@thibaultcha -

Sounds good.

When the 0.10 branch is ready for acceptance testing, please let us know and I can devote some resources for testing.

[bakstad]

Any progress on this issue?

[loicboutet]

Juste encountered this issue, any update on this ?

[MaesterZ]

+1

[kstigen]

+1

[alfirin]

Any progress on this issue please?

[subnetmarco]

Available in latest 0.10.0rc1. Please set the hosts and paths parameters when adding an API. Regex support is not enabled.

[Marak]

@thefosk @thibaultcha

I've dedicated some resources to testing 0.10.0rc1 and this feature over the next week.

Will let you know how our testing goes. Thanks again!

[phlllpe]

👍

[diegonobre]

👍

[Marak]

Initial reports from our engineers are saying that it's working. Great success so far. Thank you!

Will be moving on to stress tests in the upcoming weeks.

FYI, we've got a test suite / client adapter for the kong admin api written in Node.js. I've found a few of these already on NPM, but none of them were slim / separated concerns. Do you guys have any interest in this? I can see if the company is willing to open-source the Node.js kong admin api client library.

[thibaultcha]

@Marak Glad to hear. The new router should slightly improve performance compared to Kong 0.9 but not by a significant margin, as plugins remain the bottleneck of the proxied traffic.

Do you guys have any interest in this?

Any tool benefiting the community is most welcome! I am sure it would find its user base. Would you open-source it, we would add it to our list of community tools in this repo.

[thibaultcha]

I have opened #1970 which includes some detailed changes and documentations (non-exhaustive) concerning the new router and its capabilities, in case anyone is interested in consulting it. Reviews are welcome too (however the branch needs some cleanup).

[thibaultcha]

FYI, here is the documentation for this new router: https://github.com/Mashape/getkong.org/blob/release/0.10/app/docs/0.10.x/proxy.md

Reviews appreciated.

[thibaultcha]

Closing this as Kong 0.10.0 is now released with support for this, and regex support is part of another discussion.

[leozc]

@thibaultcha Thanks!
PS: the link to the doc is 404
https://github.com/Mashape/getkong.org/blob/release/0.10/app/docs/0.10.x/proxy.md

[thibaultcha]

Yes, the branch was merged and deleted and the doc is now published at:

https://getkong.org/docs/0.10.x/proxy/

[RodH257]

Are there plans to add the regex support at some point? It was mentioned a few times in this issue

I'd love to be able to do:
GET /accounts/:id/documents -> service A
GET /accounts/ -> service B

[thibaultcha]

Yes, see the related issue for that.

[RodH257]

Ah sorry it didn't come up on my initial searches, for others reference here is the discussion: #677

Thanks @thibaultcha !