Description
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).