[feature] Path Resolver

[thibaultcha]

First implementation of #192. After discussions, it was decided to implement a basic working version of the Path resolver but a version that introduces changes that goes towards the end-goal of supporting all discussed features of #192.

Changes

• An API must have at least a public_dns or a path.
• An API can have both.
• An API is limited to 1 public_dns and 1 path for now (we can have several at the same time later, but it'll require a heavy data migration as discussed in [request] support for routing based on path? #192).
• Upon receiving a request, Kong will load all the APIs in the system (cached for 60 seconds), and try to find a public_dns matching either the Host or X-Host-Override header. If nothing was found yet, it tries to compare the request_uri with the path currently in memory. Hence, public_dns has the priority over path.

Example:

$ curl --url http://localhost:8001/apis \
    -d "name=mockbin" \
    -d "path=/status/" \
    -d "target_url=http://mockbin.com"
201
$ curl --url http://localhost:8000/status/200
{
  "code": "200",
  "message": "OK"
}

Improvements:

• Implement a strip_path option so that /status/200 will actually resolve to target_url/200.
• Implement a coroutine that automatically reloads the APIs in memory every 60 seconds instead of waiting for a request to query it.
• Check path is alphanumeric only.
• After 0.3.0: eventually support multiple public_dns and path (this means supporting priority and regex for paths).

[sonicaghi]

@DavidTPate let us know if you have suggestion or feedback before we merge it. thanks.

[DavidTPate]

It's been awhile since I've done LUA, but it looks like path when stored in the database would be something like /status where the / would be added if not present to the beginning but the regular expression matching here doesn't check where /status is.

What it looks like to me is that if I created an API with the path /status when it gets to the comparison point it would compile the regular expression to /\/status/ (where / is my boundary character). Which means that it will match a request to /myapi/status, /status, /something/status/somethingelse/status etc. I'm not sure how you want to approach it, but Express in NodeJS land for example uses a few configuration parameters to create their Regular Expression. You can see those in path-to-regexp under the options section.

[thibaultcha]

This PR is not 100% finished, and I was thinking to simply match if the request_uri starts with the path. It's a good start and good enough for this implementation (one path per API).

I originally wanted path to be an actual regex users could set, but I think it's better to do like I just described first, and implement multiple paths and regex at the same time.

[DavidTPate]

Definitely agree, first out simply pre-pending $ to the path would be good before doing the match.

[thibaultcha]

Did you mean ^?

[DavidTPate]

Hahaha. Yeah, sorry it's been a long day.

[DavidTPate]

@sinzone Looks good to me, the only blocking issue I saw was my comments about pre-pending the path with ^ to make sure it is matching the beginning of the request_uri not anywhere within the URL and it sounds like @thibaultcha already has a plan for that.

Thanks for the quick turnaround everyone!

[thibaultcha]

👍

[ahmadnassri]

@DavidTPate thanks for the detailed feedback!

[thibaultcha]

The last 2 commits implement:

• A check for path value as suggested by @DavidTPate. It checks the path is made of the unreserved characters list of RFC 3986.
• Implement the strip_path option as suggested in the original issue.

[sonicaghi]

@DavidTPate we've released 0.3.1 - pls let us know if you have any feedback. thx! https://github.com/Mashape/kong/releases/tag/0.3.1