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

CssLinkResourceTransformer is incompatible with ContentVersionStrategy when using Caching [SPR-14597] #19166

Closed
spring-projects-issues opened this issue Aug 17, 2016 · 3 comments
Assignees
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Aug 17, 2016

Fabien Chebel opened SPR-14597 and commented

The problem

In our application, we are using a ContentVersionStrategy within Spring's VersionResourceResolver. Spring is serving 2 css files which are in the following hierarchy path:

- themes
|- alpha
   |- style.css
   |- sprite.png
|- beta
   |- style.css
   |- sprite.png

Both style.css files define different classes, so they can safely be included on the same HTML page. Each style.css file references the sprite.png file in the following way:

.alpha { 
    background-image:url("sprite.png");
}

After being processed by the CssLinkResourceTransformer and the VersionResourceResolver components, the css files look like this (assuming I load alpha/style.css in my browser first):

alpha/style.css

.alpha { 
    background-image:url("sprite-md5-of-alpha-sprite.png");
}

beta/style.css

.beta { 
    background-image:url("sprite-md5-of-alpha-sprite.png");
}

As you can see, both file names are being rewritten with the same md5 hash. I expected to get the following result for beta/style.css :

.beta { 
    background-image:url("sprite-md5-of-beta-sprite.png");
}

Problem cause

After debbuging the code for a bit, I noticed that the CssLinkResourceTransformer component forwards the png file name as is (as it appears within the "url()" declaration, so "sprite.png" in my case) to the CachingResourceResolver component via CssLinkResourceTransformer#resolveUrlPath.

After having successfully resolved the url path of the 'sprite.png' file, CachingResourceResolver#resolveUrlPathInternal proceeds to store it in its internal cache using the following cache key:

resolvedUrlPath:sprite.png

The problem is that this cache key is not unique at all. When the CachingResourceResolver is subsequently called to resolve the sprite.png file (from the beta folder), it will return the cached entry that matches the sprite.png file from the alpha folder.

So far I haven't found a reliable fix for this issue.

I know that as a workaround I can rename the 'sprite.png' file to make it unique (thus making the cache key unique), but I may not have that kind of liberty if a library loads multiple resources with the same file name.


Affects: 4.2.7

Reference URL: https://github.com/heffebaycay/spring-css-resource-issue

Issue Links:

  • #19165 VersionResourceResolver- Bug when CssLinkResourceTransformer handling relative links ("is duplicated by")
  • #18300 CssLinkResourceTransformer is incompatible with FixedVersionStrategy VersionResourceResolver
  • #19933 Regression: CssLinkResourceTransformer is now incompatible with relative links

0 votes, 5 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 17, 2016

Fabien Chebel commented

You can find a sample Spring boot application that reproduces the issue right here (along with an integration test): https://github.com/heffebaycay/spring-css-resource-issue

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 2, 2016

Fabien Chebel commented

I have submitted the following Pull request for this issue: #1192

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 11, 2016

Brian Clozel commented

This has been merged in master and should be shortly available in the next 5.0.0.BUILD-SNAPSHOT.

We've chosen not to backport this to the 4.3.x branch right now because that change of behavior could be breaking for existing applications. We can reconsider this backport after extensive testing from the community during the milestone/RC phase for Spring 5.0.0.

Please vote for this issue and raise your opinion here if you think this should be backported to 4.3.x and don't hesitate to mention specifics about your use case, including the CSS framework or open source libraries that have that behavior. This will help us reconsidering this fix.

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