Deprecate use of path extensions in request mapping and content negotiation
Closed this issue · 2 comments
The motivation for this has been described in the "Suffix Match" section of the reference docs for some time. This issue is about formally deprecating options to use path extensions in request mapping and content negotiation.
When you have to consider all of the following together: path patterns and URI variables, URL encoding (and double encoding chicanery), path parameters ";" and their treatment (and potential mistreatment) by frameworks and servers, relative paths "../", and the need for alignment between security and web framework path matching among others, it is not surprising that incidental complexity makes it hard to reason about potential attacks such as RFD (see "Suffix Match and RFD"). All of this makes the use of path extensions for request mapping and content negotiation an anti-pattern.
@RequestMapping(produces="...") should be preferred over suffix pattern matching for mapping requests with acceptable media types derived from the Accept header, or otherwise a query parameter could also be used to express acceptable format(s).
For 5.3, the defaults for suffix pattern matching will change so that only registered path extensions are used for request mapping and content negotiation, see #23915 (comment). This aligns closer with the Spring Boot web starter auto-config where the use of path extensions is off by default, and for comparison Spring WebFlux does not even have such options.
Update:
2020-04-20: the plans for 5.3 have changed after #24642, see #23915 (comment).
Currently we are setting PathMatchConfigurer.setUseSuffixPatternMatch to false. How do we advance beyond Spring 5.2.3 without a deprecated warning and keep the functionality the same? Do we have to wait for Spring 5.3 when this will presumably be the default?
If that is true would it be possible to bridge the gap with a new method like disableUseSuffixPatternMatch() that explicitly sets the value to false without causing the warning considering GA for Spring 5.3 I think I saw was October 2020?
Currently we are setting PathMatchConfigurer.setUseSuffixPatternMatch to false. How do we advance beyond Spring 5.2.3 without a deprecated warning and keep the functionality the same? Do we have to wait for Spring 5.3 when this will presumably be the default?
If that is true would it be possible to bridge the gap with a new method like disableUseSuffixPatternMatch() that explicitly sets the value to false without causing the warning considering GA for Spring 5.3 I think I saw was October 2020?
Never mind, I found the conversation you had in #24642.