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

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

Closed
spring-projects-issues opened this issue Nov 21, 2016 · 0 comments
Assignees
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Nov 21, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.