-
Notifications
You must be signed in to change notification settings - Fork 38.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate use of path extensions in request mapping and content negotiation #24179
Comments
ContentNegotiationManagerFactoryBean now ensures that ContentNegotiationManager contains the MediaType mappings even if the path extension and the parameter strategies are off. There are also minor fixes to ensure the media type mappings in ContentNegotiationManagerFactoryBean aren't polluted when mapping keys are not lowercase, and likewise MappingMediaTypeFileExtensionResolver filters out duplicates in the list of all file extensions. See gh-24179
This commit deprecates PathExtensionContentNegotiationStrategy and ServletPathExtensionContentNegotiationStrategy and also updates code that depends on them internally to remove that dependence. See gh-24179
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. |
参数名称匹配,因为后缀匹配已不被推荐使用。spring-projects/spring-framework#24179
Manually triggering controller scanning by adding an annotation handler bean does not register all useful support beans. If <mvc:annotation-driven> is used in spring-servlet.xml, all support beans are registered via WebMvcConfigurer. <mvc:path-matching suffix-pattern="true" /> need to be added because we use .do suffix for Spring actions and suffix was turned off for Spring 5.3 spring-projects/spring-framework#24179
💡 확장자로 컨텐트 협상하는 것 자체가 폐기된 내용 README.md에 적었다. * `https://github.com/spring-projects/spring-framework/issues/24179`
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 theAccept
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).
The text was updated successfully, but these errors were encountered: