Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add regression test for ambiguous router matching #5235

Merged
merged 1 commit into from
Nov 20, 2019

Conversation

rainest
Copy link
Contributor

@rainest rainest commented Nov 20, 2019

Summary

Add regression test for an ambiguous router match case involving matching prefixes on non-matching hostnames. 2683b86 fixed this issue, but was designed to address a different issue, and did not have tests for this case.

Full changelog

  • Add regression test to router unit tests.

Prior to 1.3, the router had ambiguous matching for prefix routes if a
route with a better prefix match existed for another hostname. The
router would add the better prefix match to the set of reduced
candidates, but not match it because of the hostname mismatch.

After failing to match any candidates in the reduced set, the router
would then proceed checking a larger candidate set, selecting the first
match. Because the larger candidate set was effectively sorted by
creation date, a route with a shorter, matching prefix would match
instead of a more specific prefix created later.

2683b86 fixed this issue in most cases
by adding the longest path length to route sorting criteria. It was
originally designed to fix a different issue, and as such did not test
this case.

There are some remaining edge cases. For example:

If created in the following order, versions prior to 1.3 would match
"example.com/a/b/c" to the first route, whereas 1.3+ matches the second:
"hosts":{"example.com"} "paths":{"/a"}
"hosts":{"example.com"} "paths":{"/a/b"}
"hosts":{"example.net"} "paths":{"/a/b/c"}

1.3+ will, however, still match the first route in this set of routes:
"hosts":{"example.com"} "paths":{"/a", "/long/long/path"}
"hosts":{"example.com"} "paths":{"/a/b"}
"hosts":{"example.net"} "paths":{"/a/b/c"}

Manually setting regex_priority on problem is still the recommended
means of making the second route match in the second set.
@bungle bungle merged commit 50a38d3 into next Nov 20, 2019
@bungle bungle deleted the test/longer-prefix-wins branch November 20, 2019 10:36
hutchic pushed a commit that referenced this pull request Nov 21, 2019
Prior to 1.3, the router had ambiguous matching for prefix routes if a
route with a better prefix match existed for another hostname. The
router would add the better prefix match to the set of reduced
candidates, but not match it because of the hostname mismatch.

After failing to match any candidates in the reduced set, the router
would then proceed checking a larger candidate set, selecting the first
match. Because the larger candidate set was effectively sorted by
creation date, a route with a shorter, matching prefix would match
instead of a more specific prefix created later.

2683b86 fixed this issue in most cases
by adding the longest path length to route sorting criteria. It was
originally designed to fix a different issue, and as such did not test
this case.

There are some remaining edge cases. For example:

If created in the following order, versions prior to 1.3 would match
"example.com/a/b/c" to the first route, whereas 1.3+ matches the second:
"hosts":{"example.com"} "paths":{"/a"}
"hosts":{"example.com"} "paths":{"/a/b"}
"hosts":{"example.net"} "paths":{"/a/b/c"}

1.3+ will, however, still match the first route in this set of routes:
"hosts":{"example.com"} "paths":{"/a", "/long/long/path"}
"hosts":{"example.com"} "paths":{"/a/b"}
"hosts":{"example.net"} "paths":{"/a/b/c"}

Manually setting regex_priority on problem is still the recommended
means of making the second route match in the second set.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants