Affects: Spring Framework 5.3.10
Prior discussion: https://gitter.im/spring-projects/spring-boot?at=615ffdb17db1e3753e2ba6f9
Repository showcasing the issue: https://github.com/schosin/ResourceUrlEncodingFilterPerformance
When using ResourceUrlEncodingFilter with its default configuration, invocations of HttpServletResponse#encodeURL will be wrapped by ResourceUrlEncodingResponseWrapper, which resolves URLs according to a ResourceUrlProvider.
With WebJarAssetLocator present, this will catch all URLs (/**) and test against five different locations whether the URL passed is a static resource:
[class path resource [META-INF/resources/], class path resource [resources/], class path resource [static/], class path resource [public/], ServletContext resource [/]]
For class path resources, this is done by resolving the path against the resource folder and checking calling Resource#isReadable, which ultimately throws a FileNotFoundException if the resource is not present. See PathResourceResolver#getResource(String, HttpServletRequest, List<? extends Resource>).
Since simple URLs to any handler mappings cause these checks, pages with many links will have poor performance, especialy on machines with weaker CPUs.
A workaround is to disable Spring's default resource handling (spring.web.resources.add-mappings) and registering custom resource handlers mapping handlers directly (e.g. "/css/** -> classpath:/static/css/").
Affects: Spring Framework 5.3.10
Prior discussion: https://gitter.im/spring-projects/spring-boot?at=615ffdb17db1e3753e2ba6f9
Repository showcasing the issue: https://github.com/schosin/ResourceUrlEncodingFilterPerformance
When using
ResourceUrlEncodingFilterwith its default configuration, invocations of HttpServletResponse#encodeURL will be wrapped byResourceUrlEncodingResponseWrapper, which resolves URLs according to aResourceUrlProvider.With
WebJarAssetLocatorpresent, this will catch all URLs (/**) and test against five different locations whether the URL passed is a static resource:[class path resource [META-INF/resources/], class path resource [resources/], class path resource [static/], class path resource [public/], ServletContext resource [/]]
For class path resources, this is done by resolving the path against the resource folder and checking calling
Resource#isReadable, which ultimately throws a FileNotFoundException if the resource is not present. SeePathResourceResolver#getResource(String, HttpServletRequest, List<? extends Resource>).Since simple URLs to any handler mappings cause these checks, pages with many links will have poor performance, especialy on machines with weaker CPUs.
A workaround is to disable Spring's default resource handling (spring.web.resources.add-mappings) and registering custom resource handlers mapping handlers directly (e.g. "/css/** -> classpath:/static/css/").