PathPatternParser was introduced for WebFlux in 5.0 as a replacement for AntPathMatcher that uses pre-compiled patterns, supports mapping without decoding the full URL path, and optimizes the pattern syntax for web (vs file system) paths.
It has been available for use in Spring MVC since version 5.3 and has been enabled as the default in Spring Boot since version 2.6 with https://github.com/spring-projects/spring-boot/issues/24805.
This issue is to consider switching the default in Spring Framework to PathPatternParser for 6.0, and potentially deprecate PathMatcher and related options.
Comment From: bclozel
I think we should do this (including the deprecation) for 6.0.
Comment From: rstoyanchev
Team decision: we'll go ahead with it and align with the default in Boot.
Comment From: rstoyanchev
Parsed patterns are now enabled by default in Spring MVC. This means, each HandlerMapping, or rather every subclass of AbstractHandlerMapping has a PathPatternParser instance, and that effectively means parsed patterns are used instead of String path matching with AntPathMatcher.
To minimize unnecessary breakage where intentions are clear, String path matching is still enabled through the MVC config, when either of the following is true:
- PathPatternParser is not explicitly set, while AntPathMatcher or UrlPathHelper related options are customized.
- PathPatternParser is explicitly set to null.
Further steps have also been taken to minimize failures in existing tests. For example the URL path is parsed per handler lookup if not called by the DispacherServlet, which pre-parses and caches the path. Likewise, MockHttpServletRequest detects a Servlet path mapping, to ensure a Servlet path prefix is taken into account.