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 fails when Thymeleaf and the "/**" resource pattern is used [SPR-12630] #17231

Closed
spring-issuemaster opened this issue Jan 14, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Jan 14, 2015

Christopher Savory opened SPR-12630 and commented

I could not get ResourceUrlEncodingFilter to work with Thymleaf templates. I believe the problem is that Thymleaf calls encodeURL on all of it's URLs, even standard links. What happens is that ResourceUrlEncodingFilter tries to look up resources of links and can't find them (because they don't exist, but are just mappings) and throws an exception.

I had to create my own filter based on ResourceUrlEncodingFilter that would only encode resources that had specific extensions I wanted encoded. It would be nice if ResourceUrlEncodingFilter used the same set of extensions supplied when the path patterns are supplied to ResourceHandlerRegistry.addResourceHandler and further, only those with a Transformer attached to it.


Affects: 4.1.3

Referenced from: commits spring-projects/spring-framework-issues@25f7f0d

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 15, 2015

Rossen Stoyanchev commented

The ResourceUrlProvider only tries to resolve paths that match the resource mappings. Is this with a "/\*\*" pattern for resource mappings vs something more specific like "/resources/\*\*"?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 16, 2015

Christopher Savory commented

Rossen, I think it might be related to spring-projects/spring-boot#2360, the Spring Boot WebMvcAutoConfiguration creates a mapping with ```
/**

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 20, 2015

Rossen Stoyanchev commented

I've added a repro project for this https://github.com/spring-projects/spring-framework-issues/tree/master/SPR-12630. The thymeleaf template has links to main.js (an actual resource) and another link to "/foo/bar" which isn't a resource, I'm just looking how it will be rendered. The "/foo/bar" link fails:

 [] threw exception [Request processing failed; nested exception is org.thymeleaf.exceptions.TemplateProcessingException: Error during execution of processor 'org.thymeleaf.spring4.processor.attr.SpringHrefAttrProcessor' (greeting:10)] with root cause

java.lang.IllegalStateException: Failed to get public resource URL path for foo/bar
	at org.springframework.web.servlet.resource.ResourceUrlProvider.getForLookupPath(ResourceUrlProvider.java:211)
	at org.springframework.web.servlet.resource.ResourceUrlEncodingFilter$ResourceUrlEncodingResponseWrapper.encodeURL(ResourceUrlEncodingFilter.java:78)
	at org.thymeleaf.standard.expression.LinkExpression.executeLink(LinkExpression.java:378)

We raise an ISE if a link matches a resource pattern but is not actually resolved and of course the pattern "/**" will match to anything.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 20, 2015

Rossen Stoyanchev commented

One option would be to simply remove the IllegalStateException. The Javadoc doesn't contradict:

  • @return the resolved public URL path, or {@code null} if unresolved

I suppose the intent of the exception was that if a given path actually matches a resource pattern it should resolve to an actual resource, but if the pattern is too general then that's proving to be too strict. We could try to see what kind of pattern it is but "too general" is a bit hard to define when it comes to Ant path patterns and the behavior would be inconsistent. So I propose simply dropping the check.

In the case of ResourceUrlEncodingFilter, the worse-case scenario is that the resource will still render but without changes (e.g. no version would be inserted). Hence logging would be required to track potential issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.