Kong doesn't match the longest uri when multiple uris are defined on an api #2662
Labels
Comments
|
Good catch! I remember this edge-case now and never came back to it to fix it... I just opened #2664 to take care of this. Thanks for the report! |
thibaultcha
added a commit
that referenced
this issue
Jun 30, 2017
When matching URIs, we iterate over a list of APIs, and not a list of URIs (for various, performance reasons, although a refactor of the router is scheduled with some performance improvements later on). This list of APIs is sorted per URI length. But an API can have more than one URI. As such, the router can potentially evaluate an API with a very long URI, and a much shorter one that matches the request URI, instead of a following API which would be an exact match for that API. To fix this, we sort our deserialized list of URIs to iterate on in the select method, and if we do have a match, we conserve the URI that was matched, to check if it belongs to the right API at API match time. Fix #2662
thibaultcha
added a commit
that referenced
this issue
Jun 30, 2017
When matching URIs, we iterate over a list of APIs, and not a list of URIs (for various, performance reasons, although a refactor of the router is scheduled with some performance improvements later on). This list of APIs is sorted per URI length. But an API can have more than one URI. As such, the router can potentially evaluate an API with a very long URI, and a much shorter one that matches the request URI, instead of a following API which would be an exact match for that API. To fix this, we sort our deserialized list of URIs to iterate on in the select method, and if we do have a match, we conserve the URI that was matched, to check if it belongs to the right API at API match time. Fix #2662
thibaultcha
added a commit
that referenced
this issue
Jun 30, 2017
When matching URIs, we iterate over a list of APIs, and not a list of URIs (for various, performance reasons, although a refactor of the router is scheduled with some performance improvements later on). This list of APIs is sorted per URI length. But an API can have more than one URI. As such, the router can potentially evaluate an API with a very long URI, and a much shorter one that matches the request URI, instead of a following API which would be an exact match for that API. To fix this, we sort our deserialized list of URIs to iterate on in the select method, and if we do have a match, we conserve the URI that was matched, to check if it belongs to the right API at API match time. Fix #2662
|
Thanks for the report, I just merged #2664 which takes care of this and should land in 0.11 and 0.10.4. |
|
@thibaultcha Thanks for fixing this! |
thibaultcha
added a commit
that referenced
this issue
Jul 20, 2017
When matching URIs, we iterate over a list of APIs, and not a list of URIs (for various, performance reasons, although a refactor of the router is scheduled with some performance improvements later on). This list of APIs is sorted per URI length. But an API can have more than one URI. As such, the router can potentially evaluate an API with a very long URI, and a much shorter one that matches the request URI, instead of a following API which would be an exact match for that API. To fix this, we sort our deserialized list of URIs to iterate on in the select method, and if we do have a match, we conserve the URI that was matched, to check if it belongs to the right API at API match time. Fix #2662
thibaultcha
added a commit
that referenced
this issue
Oct 19, 2017
When matching URIs, we iterate over a list of APIs, and not a list of URIs (for various, performance reasons, although a refactor of the router is scheduled with some performance improvements later on). This list of APIs is sorted per URI length. But an API can have more than one URI. As such, the router can potentially evaluate an API with a very long URI, and a much shorter one that matches the request URI, instead of a following API which would be an exact match for that API. To fix this, we sort our deserialized list of URIs to iterate on in the select method, and if we do have a match, we conserve the URI that was matched, to check if it belongs to the right API at API match time. Fix #2662
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
If two (or more) APIs have uris that match the incoming uri, Kong will route to the API with the longest uri, even if that uri is not the one that matches.
Steps To Reproduce
curl -X POST -H "Content-Type: application/json" -d '{"name":"a", "uris":"/a,/cccccc", "upstream_url":"https://google.com"}' localhost:8001/apiscurl -X POST -H "Content-Type: application/json" -d '{"name":"b", "uris":"/a/bb", "upstream_url":"https://example.com"}' localhost:8001/apiscurl localhost:8000/a/bb/123will route to google.com instead of example.comNote:
/aand/cccccare defined as separate APIs,curl localhost:8000/a/bb/123will route to example.com instead./a,/cccccwith/a,/ccin the first route,curl localhost:8000/a/bb/123will route to example.com.Additional Details & Logs
The text was updated successfully, but these errors were encountered: