This is defined as:
Name of the
{@link HttpServletRequest}attribute that contains the path within the handler mapping, in case of a pattern match, or the full relevant URI (typically within the DispatcherServlet's mapping) else.
However, PathPattern defines that case as an empty string:
https://github.com/spring-projects/spring-framework/blob/e955e52f2f108517535d4c0541cc5b8bd5e6c22b/spring-web/src/main/java/org/springframework/web/util/pattern/PathPattern.java#L278
I don't know if there was a reason for the discrepancy or if it accidental. @bclozel and @aclement do you recall anything more?
I think it would be okay to correct the behavior. The only place where this is used in WebFlux is for static resources where are typically mapped with a pattern. Now that we are adding support for PathPattenr in Spring MVC with #24945 we should correct it to make it consistent and easier to switch from AntPathMatcher to PathPatternParser in Spring MVC.
Comment From: bclozel
I can see a few tests/corner cases that we need to check for consistency once that change is in.
I don't remember a particular reason behind this behavior, besides that if there is no pattern defined, there can't be any path within a non-existing pattern. Also with that change, would those two examples yield the same result?
- pattern
"/**", path"/static/image.png"->"/static/image.png" - pattern
"/static/image.png", path"/static/image.png"->"/static/image.png"
Comment From: aclement
@rstoyanchev Sorry Rossen, I can't remember. I feel like we spent a lot of timing crafting things here though so I'm maybe a little surprised if it was accidental.
Comment From: rstoyanchev
Taking another look, PathPattern and AntPathMatcher are consistent in this regard. In SimpleUrlHandlerMapping the case when the match is not a pattern is handled as a direct hit and the path is the pathWithinHandlerMapping so no issue there. For RequestMappingHandlerMapping this is less important and is always the full lookupPath. So everything seems okay after all.