gzip compression in DispatcherServlet [SPR-11714]

[spring-projects-issues]

Christopher Smith opened SPR-11714 and commented

A very old issue to add gzip compression to the Web MVC framework was closed in favor of configuring compression at the server level, but I'd like to revisit the issue.

I've been working on adding compression as a configuration option to Spring Boot, and configuring it for either Tomcat or Jetty requires an explicit list of every content type that is eligible for compression, a list that conspicuously does not by default include application/json in either case, and can't take wildcards to compress application/*+json/xml. I've dug more into Tomcat, but configuring it requires protocol-specific casts to get to the config methods, and configuring the eligible content types is not thread safe (and in a Spring context can't reliably be done before publication). Additionally, the newer NIO connectors on Jetty and Tomcat can both have some collisions with compression.

I suggest inserting a compressing wrapper around the HttpServletResponse in the view.render call in the DispatcherServlet. Would this feature be considered "on-topic" at this point?

---

Affects: 4.0.3

Reference URL: #5514

This issue is a sub-task of #16413

Issue Links:

• Add support for compressing resources [SPR-7140] #11799 Add support for compressing resources
• GZIP compression filter [SPR-787] #5514 GZIP compression filter

1 votes, 11 watchers

[spring-projects-issues]

Juergen Hoeller commented

This isn't a bad fit with our 4.1 web theme, actually: It's all about web performance options such as cache control and resource pipelining...

brianclozel, I'm assigning this to you since you're the owner of the related issues for 4.1 as well.

Juergen

[spring-projects-issues]

Christopher Smith commented

Then I'll add a note that I'd love for the resource framework to be able to handle precompressed copies "intelligently" (e.g., serve logo.svg.gz or even logo.svgz for a request for logo.svg with gzip encoding). Is that something that would be a separate (re-raised) JIRA issue?

[spring-projects-issues]

Brian Clozel commented

Thanks Juergen Hoeller! Good idea.

Christopher Smith we're already working on a related feature for resource handling (see #15561). I guess this could be implemented using a resource resolver, checking for resources that match the resource name + extensions variants. That's definitely a use case we'll look into.

This feature is still work in progress at the moment, so expect some changes!

[spring-projects-issues]

Phil Webb commented

Brian Clozel If this makes 4.1 and there are any Boot related changes required to enable it by default could you reopen spring-projects/spring-boot#683 ?

Cheers!

[spring-projects-issues]

Christopher Smith commented

Looks like this Patrick account is a spambot.

[spring-projects-issues]

Stéphane Nicoll commented

Indeed, thanks for pinging us about it.

[spring-projects-issues]

Brian Clozel commented

Hi Christopher Smith

Here are some thoughts about this - let me know what you think!

Current limitations with using Tomcat/Jetty

I know that Tomcat and other servers aren't checking that mimetypes are compatible (in the sense of the related mime type/HTTP rfc) - but they do offer some flexibility regarding this:

• right now Jetty is doing strict string comparisons, but it also allows configuring a whiletlist/blacklist for this. Jetty is also considering improvements for this support.
• right now Tomcat is checking that the response content-type starts with one of the configured mimetypes. So configuring application/vnd.company would work for both application/vnd.company.v3+json and application/vnd.company.v2+xml

Also, you're stuck with custom configuration files or APIs when configuring this.
But when using boot, things get way easier to configure - see Boot's reference doc and spring.http.gzip.* configuration keys in the list of common application properties.

Implementing this in Spring Framework

While this is something we're considering for 4.2, I've found several drawbacks/challenges.

1. servers usually implement that support with custom, low-level APIs to be really efficient. Doing the same thing at the DispatcherServlet level (or even the Filter level) would be less efficient
2. because servlet 3.1 asyncIO support is a different beast, implementing this would only support regular IO style. This is an important drawback since serving gzipped, static resources with asyncIO support is definitely a win.
3. HTTP/2 is around the corner, and content compression is included in the protocol itself

Given the not so big limitations and the drawbacks listed above, I'm wondering if implementing this is actually worth it.

[spring-projects-issues]

cemo koc commented

I agree with Brian and believe that this issue is a better candidate for Spring Boot with low level capabilities.

Note that Jetty deprecated support for GzipFilter and It is replaced with GzipHandler.

[spring-projects-issues]

Christopher Smith commented

Given the move toward embedded containers, I think I agree with putting this in their configuration, especially as the resource system can already serve pre-gzipped static resources.

[spring-projects-issues]

Brian Clozel commented

Let's close this issue for now, as this is much better supported by containers themselves.