AntPathMatcher matches path with trailing slash differently if '**' is present in the pattern

[aomader]

I'm curious why AntPathMatcher matches a path with a trailing slash differently if the pattern contains a ** pattern. See the following example:

AntPathMatcher matcher = new AntPathMatcher();

matcher.match("/en", "/en/") == false // does not match
matcher.match("/*/en", "/en/foo/") == false // does not match
matcher.match("/**/foo", "/en/foo/") == true // does match

Could someone enlighten me why AntPathMatcher behaves this way?

[bclozel]

Is there a typo in your code snippet?

// does not match because the pattern doesn't have a trailing slash and the path has one
matcher.match("/en", "/en/")
// does not match because the pattern ends with "/en" and the path ends with "/foo/"
matcher.match("/*/en", "/en/foo/")
// this is problematic
matcher.match("/**/foo", "/en/foo/") == true // does match

I've tested the following combinations and it looks like there is an inconsistency between * and ** when it comes to matching trailing slashes.

assertThat(pathMatcher.match("/*/foo", "/en/foo")).isTrue();
assertThat(pathMatcher.match("/*/foo", "/en/foo/")).isFalse();
assertThat(pathMatcher.match("/**/foo", "/en/foo")).isTrue();
assertThat(pathMatcher.match("/**/foo", "/en/foo/")).isFalse(); // fails

I've found a fix for this issue that doesn't break any test in our test suite, but AntPathMatcher has a long history of subtle behavior and lots of people relying on it.

Using ** within patterns and trailing slashes are very likely in web applications using AntPathMatcher. There is a trailing slash matching option in Spring MVC but applications might still rely on this behavior, so I'm not tempted to fix this in the 5.3.x branch.

On the other hand, I think that using AntPathMatcher as a matcher for request patterns in Spring MVC might be retired in Spring Framework 6.0. In the 6.0.x timeline we can consider several options for AntPathMatcher:

1. keeping it around as it is and fixing small issues like this one
2. reworking it to only target file patterns use cases (and not URL path patterns which is now PathPatternParser's job)
3. or retiring it completely

In any case, this needs to be discussed within the Spring Framework team.

Did you notice this issue in a Spring MVC application while debugging the problem, or AntPathMatcher for some other use case?

[aomader]

Regarding your first question, no, I cannot see a typo. The last case is obviously the problematic one and the reason I created this issue.

Exactly, I came across this "subtle behavior" when working with Spring MVC and Spring Security. The latter I find somewhat problematic with regards to "sublte behavior"...