[MWAR-354] Generate .gz side-car files for certain resources above WEB-INF/ or in WEB-INF/resources

[jira-importer]

David Bullock opened MWAR-354 and commented

Apache Tomcat 8.0 will automatically send the pre-gzipped version of a resource if it finds a .gz version of the file in the WAR. This is beneficial since: 1) it saves on CPU cycles; 2) it can leverage the operating system to send the file 'directly' from the disk to the network socket with as little handling as possible in CPU/RAM. xref the 'Note' on the 'compression' attribute documented at https://tomcat.apache.org/tomcat-8.0-doc/config/http.html

So, I would like MWAR to do generate these pre-gzipped resources for me, at build time. Obviously, it need only do so for certain static assets: an initial 'by convention' would probably:

• include *.html, *.jpg, *.png, *.gif, *.css files under the WAR resource root or subdirs
• but exclude those found under /WEB-INF/
• except if they were specifically found under /WEB-INF/resources/

---

No further details from MWAR-354

[jira-importer]

Karl Heinz Marbaise commented

Of those files should be left only the .gz files ?

By WAR resources root or subdirs you mean ? Can you make an example how it looks like ? Would help me...

[jira-importer]

David Bullock commented

Hey thanks for picking this request up. You can leave the un-zipped resources in the archive. So if I had:

/index.html
/css/main.css
/images/alreadysmall.jpg
/WEF-INF/notme.html
/WEB-INF/resources/other.html

By default,

• CSS and HTML files would be gzipped if they met this filter: (filepath.startsWith("/WEB-INF/resources/") || !filepath.startsWith("/WEB-INF/")) (because except for /WEB-INF/resources/, nothing under /WEB-INF/ gets served by the servlet-engine)
• Already-compressed graphics files would probably NOT be gzipped (contrary to what I said above)

Giving:

/index.html
/index.html.gz
/css/main.css
/css/main.css.gz
/images/alreadysmall.jpg
/WEF-INF/notme.html
/WEB-INF/resources/other.html
/WEB-INF/resources/other.html.gz

[jira-importer]

David Bullock commented

I am aware that this is a pretty marginal performance tweak. Just to keep in mind what we actually do gain:

• we can take time to compress the file well, saving precious bits because we are only doing the compression at build time
• Tomcat serves the file efficiently from the point of view of conserving operating system resources, bypassing unnecessary copying of the bits of the file into userspace memory, and then out again

[jira-importer]

David Bullock commented

An implementation note:

• Google now has Brotli and it would seem to be a matter of time before Tomcat would support a similar idea for that encoding (probably with a the extension .br). So although one would not do the work of a Brotli compresssion algorithm prematurely (YAGNI), one should anticipate this by suitable decoupling in code and some forethought for how to specify which algorithms to apply in future. If multiple algorithms are supported, I would expect that some clients will ask for GZIP encoding, and others for Brotli encoding, such that both .gz and .br forms will need to be generated in the future.

[jira-importer]

Michael Osipov commented

Apache Tomcat 8.0 will automatically send the pre-gzipped version of a resource if it finds a .gz version of the file in the WAR.

Where is this documented? Jetty does this, but Tomcat...? It compresses on the fly.