Determination of the best pattern match to map a handler to an URL [SPR-7589]

[spring-projects-issues]

Nicolas Demengel opened SPR-7589 and commented

Hi people,

I might have found an odd behavior in the AbstractUrlHandlerMapping class : given two controllers, one annotated with @RequestMapping("/**") and the another one annotated with @RequestMapping("/access/{resourceType}/{resourceSubType}/{resourceName}"), when the path "/access/document/text/sometextdocument" is evaluated I would expect the second controller to be chosen to handle the request but it is the first one that is taken.

Looking at the code of AbstractUrlHandlerMapping.lookupHandler() one can see that when several patterns are found that match the path, they are ordered using an AntPatternComparator to find the most pertinent one for it. Digging in further, this comparator orders patterns based on their level of incertitude, counting the occurrences of wildcards and brackets. In my opinion it should read patterns as we do (i.e. from left to right in our countries) to see if the pattern start makes it more suitable to handle the path that is evaluated.

I attached a JUnit test to illustrate my point.

Thanks

---

Affects: 3.0.4

Attachments:

• AntPatternComparatorTest.java (1.45 kB)

Issue Links:

• RequestMapping with 3 PathVariable doesn't work [SPR-6741] #11407 RequestMapping with 3 PathVariable doesn't work ("duplicates")
• AntPathMatcher.AntPatternComparator algorithm wrong for hierarchical matches [SPR-8683] #13325 AntPathMatcher.AntPatternComparator algorithm wrong for hierarchical matches

1 votes, 1 watchers

[spring-projects-issues]

Andrew White commented

I just got bit by this bug as well. The ant comparator seems to make assumptions about the specificness of a match prematurely based only on the number of wildcards/brackets. For example...

Given the request /user/id/property/value the comparator will rank the following patters in the following order

1. /user/**/{a}/{b} <-- Because it only has 2 brackets
2. /user/**/{a}/{b}/property/{c} <-- vs 3 brackets here

However, it seems clear that (2) is more specific. Namely because it has more brackets that are assignable given the input.

For now, what is the best workaround? Simply avoid these patters (can be hard to do in some cases)? Is there a way to inject an alternate comparator?

[spring-projects-issues]

Nicolas Demengel commented

Hi Andrew,

I'm the original reporter of this bug. As far as I remember I could not found any way to inject an alternate comparator (or maybe I didn't want to...), but as you can see in the attached java file I could find a workaround. It's ugly but it worked for me. In your case it would consist in rewriting "/user//{a}/{b}" to become "/user///{a}/{b}". As "" and "/" evaluates in the same way, it does not change the meaning of your mapping, but it does increase the number of stars thus making this mapping less likely to be used .

Regards,
Nicolas

[spring-projects-issues]

Nicolas Demengel commented

It looks like my stars were interpreted as formatting characters. Here is the correction:

In your case it would consist in rewriting ```
/user/**/{a}/{b}

```/user/**/**/{a}/{b}
```. As 
```**
``` and 
```**/**
``` evaluate in the same way, it does not change the meaning of your mapping, but it does increase the number of stars thus making this mapping less likely to be used .

[spring-projects-issues]

Andrew White commented

Thanks, I actually ended up doing something very similar but it'll nag at me until it's fixed :) I did find out that you can extend the AntPathcerMatcher and override the comparator if needed. However, I have a feeling that making a "correct" comparator will be non trivial so I opted for a the quick fix for now.

On a side note, it would be nice if Spring at least had a DEBUG log output for the candidates and the resulting order so we don't have to dig so deep to find the cause of the oddness.

[spring-projects-issues]

Andrew White commented

I should also add that I am seeing this in 3.0.5 as well.