allow for combining request_path and request_host for matching API rules

[ahmadnassri]

currently the routing uses either request_path or request_host (with the latter taking priority) to determine appropriate routing rules.

should allow for combined usage, so only when both properties are matched (if defined) is the route valid.

[NicholasIoanJones]

Just writing to support this feature. It would be really useful to be able to match on both.

[oholubyev]

👍 would love to have this feature

[discobean]

+1 I thought this was the default method when first evaluating Kong and was surprised it wasn't

[raskawa]

+1 this is really inhibiting our use of Kong, would love to see this added.

[thibaultcha]

Could you please describe your use cases and why this feature is mandatory for it? Very often users believe they need both properties to fit their use case when in reality they simply need to properly use only one of them.

[raskawa]

Yes, so if I want to do:

(assume entered into the api admin in this order for simplicity of explaining)

1. http://foo1.com/* => internal-foo1.com/*
2. & http://foo1.com/topics/ => internal-foo1.com/topics/
3. & http://foo1.com/topics/birds => internal-foo1.com/topics/flyinganimals
4. % http://foo2.com/topics/ => internal-foo2.com/topics/
5. http://foo2.com/topics/cats => internal-foo2.com/topics/cats
6. & http://foo2.com/topics/birds => internal-foo2.com/topics/birds

The one's with a & just won't work (because you can't have a duplicate hostname using request_host)
And the one's with a % won't work because they would create a duplicate path as a endpoint WITHOUT request_host

If Kong looked at both request_host and request_path as a AND condition for matching instead of only independent of each other when both exist, then you could have the best of both worlds.. instead I think it was intended as a OR which is not really useful (even if someone does that, they can instead put two API endpoints in to deal with that problem...currently I am blocked with no workaround)

This is a real use case.. The only way to workaround currently is to ignore request_host and make a artificial api path mechanism to deal with it:

1. http://foo1.com/foo1/* => internal-foo1.com/*
2. http://foo1.com/foo1/topics/ => internal-foo1.com/topics/
3. http://foo1.com/foo1/topics/birds => internal-foo1.com/topics/flyinganimals
4. http://foo1.com/foo2/topics/ => internal-foo2.com/topics/
5. http://foo1.com/foo2/topics/cats => internal-foo2.com/topics/cats
6. http://foo1.com/foo2/topics/birds => internal-foo2.com/topics/birds

This is not ideal.. does that all make sense?

[JnMik]

@raskawa Just curious, why would you want your Gateway to front all the routings of the API behind ?

I usually consider the first part of the URL ('till the version number) belongs to kong to manage, and the rest belongs to the API.

Exemple of an API setup

request_path: "/api-name/1.0"
upstream_url: "http://api-host:port/1.0"

If you do a major breaking change in the API, you can release a new API with version tag 2.0, and setup a new api definition for it (this would allow you to keep the 1.0 running until you move all your applications to the new one).

If you do a minor change in the API, like renaming a birds route to flyinganimals route, should it be your API job to handle both routing pointing at the same place ?

Cheers !

[raskawa]

Sorry - I see the confusion - foo1 and foo2 was not meant to be indicative of api versioning. They are different microservices that have similar named endpoints. It's even more complicated because there is a real possibility of duplicates endpoint paths - I will rewrite the example.. let me know if that makes more sense.

1. http://forumservice.com/* => internal-forumservice.com/*
2. & http://forumservice.com/topics/ => internal-forumservice.com/topics/
3. & http://forumservice.com/topics/birds => internal-forumservice.com/topics/flyinganimals
4. % http://chatservice.com/topics/ => internal-chatservice.com/topics/
5. http://chatservice.com/topics/cats => internal-chatservice.com/topics/cats
6. & http://chatservice.com/topics/birds => internal-chatservice.com/topics/birds

The one's with a & just won't work (because you can't have a duplicate hostname using request_host)
And the one's with a % won't work because they would create a duplicate path as a endpoint WITHOUT request_host

[JnMik]

Hello @raskawa, I understand that foo1 and foo2 are different APIs and not version tag, but this can be manage either way in the URL part that is managed by kong.

Let me put an example of how I see it :

gateway.raskawa.com/foo1/1.0/same-exact-routing
gateway.raskawa.com/foo2/1.0/same-exact-routing

Kong would have 2 API definitions, with different request path
#1 /foo1/1.0
#2 /foo2/1.0

Behind this you would have two APIs which shared a routing, but will not conflict because Kong consider foo1 and foo2 to be two distinct dispatch routes, each representing a different service.

Would this scenario be working for you ? :)

[JnMik]

Rephrasing with your DNS names

These would be management by Kong, as request path :
forumservice.com/internal/1.0/ -> your internal-forum-service
forumservice.com/chat/1.0 => your chat service

[raskawa]

JnMik,

Thanks for the suggestion, but we have and would like to continue using domain name as the appropriate way to identify our microservices. Unlike a consumer facing API (where a single URL would make more sense) we are trying to use Kong as a API Gateway for our services internally for its routing/control and security benefits.

I don't understand if this is an architecture decision where it's never going to happen / does not fit the vision of Kong or it's just a feature that needs to be done. It seems like it has huge potential for Kong usage/flexibility -- add on wildcard capability in request_path and you will have a hard time finding a use case in the API Gateway role that Kong can't be used.

[JnMik]

@raskawa I understand, unfortunately I can't help with that.
Hoping a Mashape dev will take over and deploy the solution for your issue :)

Good luck !

[engineeringstuff]

We've modded the internals of Kong to accommodate for this, but not pushed back to the community because of this open issue (we were hoping Mashape would have addressed this) and another issue which seems to express a desire for a complex priority based routing #369 .

In our case we've modified Kong to act as a AAA gateway for any HTTP traffic (websites, REST APIs etc.) - obviously for websites we want some areas to allow anonymous access, and other areas to be secure, this issue is crucial to enable that functionality (although I appreciate that KONG is not an AAA gateway by design).

[raskawa]

@worktick Yeah, I am looking at making a local mod, but would much rather see a release with it.. When you say AAA gateway - is that a acronym for something or do you mean like premium / paid gateway? Just curious as I am coming up to speed in these discussions.

[engineeringstuff]

@raskawa it means Authentication, Authorization and Accounting (see https://en.wikipedia.org/wiki/Diameter_protocol) it's pretty standard terminology from what I know.

[williamhorstkamp]

Just adding that this feature would be incredibly useful for how we intend to use Kong.
Hoping we don't have to go the route @worktick went and modify it ourselves.

[rogoman]

Any update on this?

[ghost]

Bump. This would be useful for my case too.

[HenryChelsea]

Sure. This is useful!!!

[HenryChelsea]

Any update on this? Hope add this feature!

[thibaultcha]

Yes, as a matter of fact and coincidentally, I posted such an update today on #1411:

An update on this: see the feat/new-router branch to track the progress on the new router which will implement method restriction directly into the core.

The new router is kong.core.router in the feat/new-branch branch.

[HenryChelsea]

Hi @thibaultcha , thanks for the reply. I I have reviewed your code (branch feat/new-router) already , it was good . Good job. 😁

[HenryChelsea]

@thibaultcha have some issues. Branch feat/new-router

curl http://127.0.0.1:8001/apis -X PUT -i -H "Content-Type:application/json" -d '{"name": "ccc", "request_host": "test.com", "request_path": "/v2", "upstream_url": "http://127.0.0.1"}'

HTTP/1.1 400 Bad Request
Date: Wed, 07 Dec 2016 11:53:21 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Access-Control-Allow-Origin: *
Server: kong/0.9.6

{"request_path":"request_path is an unknown field","request_host":"request_host is an unknown field"}

[HenryChelsea]

@thibaultcha Seems you have changed apis.

--request_host = {type = "string", unique = true, func = check_request_host},
--request_path = {type = "string", unique = true, func = check_request_path},

hosts = {type = "array", default = {}, func = check_hosts},
uris = {type = "array", default = {}, func = check_uris},
methods = {type = "array", default = {}, func = check_methods},

[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).

[Tieske]

merged and waiting for release 0.10.0, available in the RC for 0.10. Closing this now.