Skip to content
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

Closed
rstoyanchev opened this issue Dec 10, 2019 · 2 comments
Closed
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: documentation A documentation task
Milestone

Comments

@rstoyanchev
Copy link
Contributor

rstoyanchev commented Dec 10, 2019

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

@rstoyanchev rstoyanchev added type: documentation A documentation task in: web Issues in web modules (web, webmvc, webflux, websocket) labels Dec 10, 2019
@rstoyanchev rstoyanchev added this to the 5.2.3 milestone Dec 10, 2019
@rstoyanchev rstoyanchev self-assigned this Dec 10, 2019
@rstoyanchev rstoyanchev modified the milestones: 5.2.3, 5.2.4 Jan 13, 2020
rstoyanchev added a commit that referenced this issue Jan 22, 2020
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
rstoyanchev added a commit that referenced this issue Jan 22, 2020
This commit deprecates PathExtensionContentNegotiationStrategy and
ServletPathExtensionContentNegotiationStrategy and also updates code
that depends on them internally to remove that dependence.

See gh-24179
@rstoyanchev rstoyanchev changed the title Deprecate use of path matching and content negotiation via path extension Deprecate use of path extensions in request mapping and content negotiation Jan 22, 2020
@kev22257
Copy link

kev22257 commented Apr 13, 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?

@kev22257
Copy link

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.

think-gem added a commit to thinkgem/jeesite5 that referenced this issue May 5, 2020
MarcinCieslak added a commit to lamsfoundation/lams that referenced this issue Nov 29, 2021
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
fp024 referenced this issue in fp024/spring-5-recipes-study Sep 21, 2023
💡 확장자로 컨텐트 협상하는 것 자체가 폐기된 내용 README.md에 적었다.
  * `https://github.com/spring-projects/spring-framework/issues/24179`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: documentation A documentation task
Projects
None yet
Development

No branches or pull requests

2 participants