-
Notifications
You must be signed in to change notification settings - Fork 621
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
route precendence #389
Comments
Just a general question as it relates to some things we've been investigating as well. Do you specifically need route prioritization or would a general most specific match priority work? With a most-specific-match first assuming you had the following tags:
A request to |
What @leprechau is describing, a most-specific-match, is ultimately what we want. |
It wouldn't be perfect but I think you could get very close to 'most-specific' by just checking the matches (urlprefixes) sorted by length (longest first). This might be easier to implement and also resolve the issue along with documentation of how it works? |
Sure, I would be fine with that implementation. It would solve my use-case. |
Although, just going by length would mean
would have the same precedence. I don't have any single character subdomains I need to be concerned about, but someone might. |
Right, that was the 'very close' part of the above comment :) ... it's absolutely not perfect but it may be less logic than actually trying to analyze the specify of the match. I have no real skin in the game at the moment, just trying to float some ideas. I'm sure @magiconair has his own thoughts on the matter. |
Looking at the code a bit this may be how it is already supposed to function: https://github.com/fabiolb/fabio/blob/master/route/table.go#L90-L93 |
Looked through the code some more and found the https://play.golang.org/p/ZfspewZRxC Really curious about the exact routes you are using now. Doing it by length is definitely wrong after looking at the output of my playground test. |
@tomwganem Could you post a trace log? https://github.com/fabiolb/fabio/wiki/Features#request-tracing |
I was unable to get tracing working. Not sure what i'm doing wrong. For reference, I am using docker image fabiolb/fabio:1.5.3-go1.9.2. Here are my routes
So in the above routing table, most of all of our requests are going to the service called 'files', which will serve up a webpage with some javascript. Here's me curling a page I know should be routed to the
And now I will try to curl api.asperafiles-dev.com. As you can see, I am still getting routed to the
|
I don't think it sorts correctly now, as it uses The first question to answer is which part is more important: the domain part or the url part. Because basically all route definitions are I would say this makes sense for a default order of precedence:
This works based on length now, besides 2 (which might also be controversial), but it doesn't if we use:
|
Paths are already sorted from most to least specific. I think the issue is in the host matching. |
|
This patch ensures that exact hostname matches are preferred over glob matches. Fixes #389
The problem was in that function but not where I thought. The issue is that the The patch I've put in #390 fixes this but I still need to test whether it matches |
I guess this should work since |
This patch ensures that exact hostname matches are preferred over glob matches. Fixes #389
This fix doesn't work properly yet. There is still a random element in there. Looking |
This patch ensures that exact hostname matches are preferred over glob matches. Fixes #389
Found it. This should work now. |
This patch ensures that exact hostname matches are preferred over glob matches. Fixes #389
This patch ensures that exact hostname matches are preferred over glob matches. Fixes #389
I can confirm that #390 fixes the behavior I was seeing 👍 |
This patch ensures that exact hostname matches are preferred over glob matches. Fixes #389
This patch ensures that exact hostname matches are preferred over glob matches. Fixes #389
I don't see this issue listed in the existing milestones, is this to be included in 1.6 or in a 1.5.x release? And is there an ETA on that release? |
I've tagged it now for 1.6 but I'll probably roll a 1.5.4 for this since the metrics refactor takes longer than expected. |
Will be released this week. |
EDIT: Forgive me, I just found #506, which appears to be this exact issue. Hello, I'm seeing an issue with route precedence in the We have the rules:
Running
(Same result for I would expect it to take the longest/most specfic host first, and match the It appears that non-wildcard routes take precedence, but among wildcard routes themselves, there is noe specific precedence. Is there any way to work around this for now without having to use paths? Like any way to use regexes in the hosts so Thanks! |
My problem is this: I have several subdomains that I want routed to specific containers, like such:
urlprefix-foo.domain.com/
urlprefix-bar.domain.com/
But beyond my list of specific of subdomains, I want to redirect all other subdomains to just one container.
urlprefix-*.domain.com/
The problem is that when I put in a route like
*.domain.com
, it takes precedence over the other routes, so they no longer work.I have a workaround for now, which is:
urlprefix-foo.domain.com/
urlprefix-bar.domain.com/
urlprefix-*.domain.com:9997/
But I would rather just be able to set a precedence/priority, something like:
urlprefix-foo.domain.com/ #=1
urlprefix-bar.domain.com/ #=2
urlprefix-*.domain.com/ #=100
The text was updated successfully, but these errors were encountered: