Can GzipHandler check if .gz file exists only by some paths?

[btd]

I think title is pretty clear, but would like to explain my usecase (i think it is pretty common). We have some asserts (js and css file) that we build using some frontend tools and we can prepare .gz files exactly for them. It makes more sense to add filter by path exactly for this files (or prefixes) to do not check each request for extract IO if such file +.gz exists.

What do you think?

[sbordet]

Are you proposing that we match realPath against a list of strings that you would be able to configure in GzipHandler ?

So basically replacing a single File.exists() call with possible multiple String.startsWith() (or similar) ?

[joakime]

GzipHandler has configurables for include path and exclude path.

And those paths are checked before the *.gz tests.

Also the *.gz check (and associated checkGzExists boolean configurable) is only an optimization to test for the existence of gzip work that the DefaultServlet will actually perform.

[btd]

Common include and exclude path is not working for my case.

I want all my 'allowed' dynamic resources will be gzipped as it now. But only some of them e.g by path /public/* or /assets/* will be checked if .gz file presented (because i know exactly this file i prepare).

[sbordet]

@btd so answers to my questions are "yes" and "yes" ?

I'm not sure a single check to the filesystem is slower than multiple checks on strings.

[joakime]

I wonder if the entire check for *.gz can even be removed from GzipHandler and just have those served from DefaultServlet (like it would be without GzipHandler), but with GzipHandler being smart enough to not recompress the content served from DefaultServlet does (like setting the ETag header on the response)

@gregw what you you think?

[gregw]

@joakime I'm struggling to remember why we actually do need to check for the *.gz in the gzip handler still. It made sense when we wanted to avoid wrapping as the filter did (as this would prevent efficient sendContent calls).

But now with the interceptor, I don't see there is much need. It will install an interceptor, but it is smart enough to see the content is already compressed.

The ability to disable the check already exists, so I'd suggest some benchmarking with and without to see which is best.

[joakime]

The biggest impact on the check gz test in GzipHandler is when a servlet base resource is a collection of paths to check.
We should remove this check if its not needed anymore.

[joakime]

Pushed commit c008f90 to branch jetty-9.4.x-issue-987-gziphandler-gzexists that just removes the whole check-gz-exists concept from GzipHandler.
Local testing shows no test failures using this commit. Going to let CI do a build once too.

[joakime]

Closing as fixed.

The next jetty-9.4.x release will have checkGzipExists set to false by default.

jetty-10.0.x has the entire concept removed from GzipHandler.