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 should not transform gzipped CSS files [SPR-14773] #19339

spring-issuemaster opened this issue Oct 1, 2016 · 1 comment


Copy link

commented Oct 1, 2016

Martin Hock opened SPR-14773 and commented

CssLinkResourceTransformer is not working if you are using gzipped CSS files. Here is a example configuration:

VersionResourceResolver versionResolver = new VersionResourceResolver().addContentVersionStrategy("/**");

                .addResolver(new GzipResourceResolver())
                .addResolver(new PathResourceResolver())
                .addTransformer(new CssLinkResourceTransformer());

The links will not be modified within a CSS file, if you have a gzipped file. The problem is that the links could not be find due to this line in CssLinkResourceTransformer:

byte[] bytes = FileCopyUtils.copyToByteArray(resource.getInputStream());

If this is a gzipped file it should be decompressed first or if available the uncompressed version should be used.

Affects: 4.3.3

Referenced from: commits cb44f27


This comment has been minimized.

Copy link
Collaborator Author

commented Nov 16, 2016

Brian Clozel commented

This is now fixed.

Automatic resolution of gzipped resources is primarily for resources that should not be transformed at runtime. CSS files do not fall in that category. The goal of the GzipResourceResolver is to avoid compressing resources at runtime (usually the container does this).

So your best bet here is to not pre-compress CSS files if you wish them to be transformed at runtime.

While looking at this I've found that the CssLinkResourceTransformer would try to transform gzipped CSS resources, even if the body can't be parsed. I've added a new check to make sure that we don't try to read the resource content if it's a GzippedResource.

Thanks for the report!

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