-
Notifications
You must be signed in to change notification settings - Fork 37.7k
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
Revisit AntPathMatcher's handling of patterns with file extensions [SPR-7336] #11995
Comments
Luke Taylor commented Did you mean to register this against Spring? |
marc schipperheyn commented yeah, sorry. |
John Latham commented Hmmm, this has gone from Bug to Improvement. Is behaviour of AntPathMatcher supposed to be consistent between 2.5 and 3.0? It isn't consistent in my experience. Is that known? Please advise whether I should log details of differences on this issue or create another. |
marc schipperheyn commented Yeah, AFAIC it's a bug |
marc schipperheyn commented As a solution direction you could offer an overridable isBetterMatch(String currentPath,String otherMatchingPath) method that retains current functionality and that you potentially implement later in a different manner protected Integer lookupCacheSeconds(String urlPath) {
// direct match?
Integer cacheSeconds = this.cacheMappings.get(urlPath);
if (cacheSeconds == null) {
// pattern match?
//This determines the best pattern bij simply looking if the matching patterns is the longest
String match = "";
for (String registeredPath : this.cacheMappings.keySet()) {
if (this.pathMatcher.match(registeredPath, urlPath)) {
match = isBetterMatch(match,urlPath);
}
}
cacheSeconds = this.cacheMappings.get(match);
}
return cacheSeconds;
}
public String isBetterMatch(String currentPath,String otherMatchingPath){
return true;
} |
Rossen Stoyanchev commented Although I'm not sure what we should do yet, it clearly looks like something needs to be done. The cacheMappings in WebContentInterceptor are not sorted with AntPathMatcher PatternComparator. The order in which patterns are listed is not preserved either. Furthermore we keep going and return the last match where in fact any match is as random as the next. I'm actually not sure why the original description states the result of specific URLs where the result can be different each time as far as I can see. Am I missing anything? If the result is truly random as it seems to be, then we can take our picks for the fix without backwards compatibility issues. The use of AntPathMatcher/Comparator with some protected method to override might make the most sense. |
Closing as outdated. We've deprecated and turned off support for suffix pattern match in #23915 and related issues. We've added support for pre-parsed |
marc schipperheyn opened SPR-7336 and commented
The AntPathMatchers in some cases prefers less specific matches over specific matches. This examples is from the case of
WebContentInterceptor
The order doesn't matter. The issue occurs also if we put /**/ at the bottom
Example urlPath
result: 1800. Should be -1
Example urlPath
result: -1 correct
It seems that the issue doesn't occur when the path ends with a / in stead of with an extension *.html
Affects: 3.0.3
2 votes, 4 watchers
The text was updated successfully, but these errors were encountered: