-
Notifications
You must be signed in to change notification settings - Fork 27
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
Match ns prefix by longest match, not first match #142
Match ns prefix by longest match, not first match #142
Conversation
Previously, when two namespaces like /chtc and /chtc/PUBLIC existed in the cache, the matchPrefix function wound up matching whichever happened to be read first. Now it matches against the longest prefix, so a request for path /chtc/PUBLIC/foo/bar will always match /chtc/PUBLIC. Closes issue PelicanPlatform#140
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation looks correct.
However! An important push for v7.1.0 is unit tests -- can you please add a regression test covering this function as part of the PR?
Unsurprisingly, it turns out writing the unit test was a great idea because it caught an additional bug that was a bit more nuanced. This time, the bug came from the fact that some caches/origins might support a namespace prefix that's shorter than the best/ longest prefix without supporting that longest prefix. In those cases, the wrong namespace (and slices of origins/caches) might wind up being returned not by `matchesPrefix`, but by `GetCacheAdsForPath` due to the fact that `/chtc` IS the best namespace prefix for the path `/chtc/PUBLIC/foo` if a cache only supports `/chtc`. I don't love all having to deal with all of these trailing /'s, but because I'm assuming there's a reason that was allowed in topology, so I'm hoping my test cases are robust enough to catch all the nuanced edge cases.
A very good idea -- caught a more nuanced bug in the process of writing the test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a trivial typo in a comment. Otherwise, let's go.
Previously, when two namespaces like /chtc and /chtc/PUBLIC existed in the cache, the matchPrefix function wound up matching whichever happened to be read first. Now it matches against the longest prefix, so a request for path /chtc/PUBLIC/foo/bar will always match /chtc/PUBLIC.
Closes issue #140