ResourceUrlEncodingFilter, ResourceUrlProvider should correctly resolve hash'ed resource paths [SPR-14928]

[spring-projects-issues]

Marc Vanbrabant opened SPR-14928 and commented

This popped up when debugging a production issue, where a lot of calls to ResourceResolver.resolveResourceInternal() were showing in the CPU profiler.

We use thymeleaf 2.x (but thymeleaf 3 on spring 4.3.2 seems affected as well). When a LinkExpression is evaluated in Thymeleaf with the value of "/resources/main.svg#mail", the CachingResourceResolver.resolveResourceInternal will return null and not ever cache this resource (this seems correct up to a point).

The entry points are ResourceUrlEncodingFilter.encodeURL() - the argument being "/resources/main.svg#mail" which gets passed to resourceUrlProvider.getForLookupPath(lookupPath) which eventually returns null.

In the end we fall back on "return super.encodeURL(url);" call which leaves this url as-is.

Note that the same call with "/resources/main.svg" correctly caches and resolves the resource. Maybe it seems sane to ignore everything behind the hash when finding the resource?

Brian Clozel Juergen Hoeller any ideas if this is a "bug" or should we work around the issue ourselves?

For reference, this is used by often with svg's like so: https://css-tricks.com/svg-use-external-source/

Where

th:attr="'xlink:href'=@{'/resources/main.svg#icon-hamburgermenu'}"

I suppose this is a corner case but note that HttpServletResponseWrapper also correctly handles #hashed urls when calling encodeURL()
Likewise I would expect all ResourceResolvers (CachingResourceResolver and VersionResourceResolver at least) to do the same.

---

Affects: 4.1.9, 4.3.2

Referenced from: commits b59455b, 933f150