spring-boot: Spring WebFlux with Netty Doesn't Gzip Static Resources Correctly
Spring Boot Version
Tested with 2.0.1.RELEASE and the latest commit on master c43eb898238fd334c.
Issue
When using Spring WebFlux with Netty and Gzip compression is enabled, the HTTP response correctly contains the content-encoding: gzip header, but the actual response body isn’t compressed. This will cause Chrome to fail with ERR_CONTENT_DECODING_FAILED. Switching to a different sever, such as Undertow or Tomcat, will yield the correct result. Response bodies returned from a router function that are large enough to trigger compression seem to work fine, it only appears to happen for static resources.
Reproduction Steps
Using the spring-boot-sample-webflux project, create a public directory in src/main/resources/ and place this text file in there. Run the project with mvn spring-boot:run -Dserver.compression.enabled=true and navigate to http://localhost:8080/test.txt.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 35 (23 by maintainers)
I’ve seen that problem before with Gradle, and others have too. I can’t be 100% certain, but I don’t think it’s relevant here.
I’ve tried the same with Spring Boot 2.1.0 (reactor-netty 0.8.x), and it works now.
There was a lot of rewriting and moving things around in the 0.7 -> 0.8 process, and it seems that this extra compression check on
HttpServerOperationsgot lost in the process.On the Spring Framework side, the resource handling code hasn’t changed a bit, so I’m thinking about an accidental fix in 0.8, or even working by accident in 0.8. Either way, we need to let the Reactor team know about this.
I’ve raised reactor/reactor-netty#430 as a follow up of this issue.
I’ve opened the above Reactor Netty issue to address this.