WebFlux EncodedResource wrong mapping for encoding

[userquin]

EncodedResource calls original.createRelative(original.getFilename() + extension) that resolves the name twice:

<somapath>/a.html becomes <somepath>/a.html/a.html.gz or <somepath>/a.html/a.html.br

Must be changed to resolve via original URL or check for Resource type and use it (FileSystemResource, ClasspathResource, etc...)

[rstoyanchev]

We have tests with ClasspathResource locations, which uses StringUtils#applyRelativePath and works as expected. FileSystemResource uses the same.

So I'll need more specific instructions how to reproduce the issue, or best if you could provide some test that demonstrates the issue?

[userquin]

I have a coRouter dispatching all static resources to a FileSystemResource with spring.resources.chain.enabled=true and spring.resources.chain.compressed=true.

When the browser requests for example /index.html with Accept-Encoding: deflate, gzip, br header, the chain on the server will getResource twice, the fisrt one using PathResourceResolver to resolve the /index.html and the second one using EncodedResourceResolver to check for .gz and .br variant for /index.html.

The problem resides on EncodedResourceResolver: when an acceptable encoding is found, following with the sample, lets say /index.html.gz, then EncodedResourceResolver, returns an EncodedResource (private inner class of EncodedResourceResolver) which in its constructor calls original.createRelative(original.getFilename() + extension), and then here is the problem: instead resolving to /index.html.gz it resolves to /index.html/index.html.gz.

[userquin]

It seems to be related on my another issue, when FileSystemResource contains ..: #24211

[rstoyanchev]

Thanks for the extra information but that still doesn't give me a sufficient information. I have read #24211 but I still can't think of a way to reproduce the issue described here that would append instead of replace at the end of the root path.

I understand you believe the problem is in the constructor of EncodedResource but that constructor is using the "proper" way to create a relative path through the underlying Resource abstraction. If anything there might be something to do in spring-core as part #24211 but I don't see any issue in the logic of EncodedResource itself.

Please provide a failing test, if you would like this issue to be looked into further.

[userquin]

I close it: later at home I will check it again and I'll try to provide a test project if still failing and reopening if necessary...