Side effect from ProducesRequestCondition cache with multiple RequestMappingHandlerMapping beans #23091
Assignees
Labels
in: web
Issues in web modules (web, webmvc, webflux, websocket)
type: enhancement
A general enhancement
Milestone
Comments
spring-projects-issues
added
the
status: waiting-for-triage
sbrannen
added
in: web
rstoyanchev
removed
the
status: waiting-for-triage
rstoyanchev
changed the title
bclozel
added a commit
to spring-projects/spring-boot
that referenced
this issue
Feb 17, 2020
As of spring-projects/spring-framework#22644, Spring Framework caches the "produces" condition when matching for endpoints in the `HandlerMapping` infrastructure. This has been improved in spring-projects/spring-framework#23091 to prevent side-effects in other implementations. Prior to this commit, the Spring Boot actuator infrastructure for `EndpointHandlerMapping` would not clear the cached attribute, presenting the same issue as Spring Framework's infrastructure. This means that a custom arrangement with custom `HandlerMapping` or `ContentTypeResolver` would not work properly and reuse the cached produced conditions for other, unintented, parts of the handler mapping process. This commit clears the cached data and ensures that other handler mapping implementations are free of that side-effect. Fixes gh-20150
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The fix for #22644 introduces an optimization by storing the calculated accept headers in a request attribute for later lookups. If a
HandlerMappingimplementation decorates the request hoping that Accept headers would be looked up through that decorator, this fails as the cached values get used.I suggest to reset the cache per
HandlerMappingso that it's able to tweak thhe request early in the processing cycle but still benefit from the cache.The text was updated successfully, but these errors were encountered: