Bug 54095 adds support for pre-compressed files, but the pre-compressed file needs to be the name of the originally-requested resource + ".gz". This isn't convenient for other file name patterns -- for example "*.svg" -> "*.svgz". Being able to specify a list of pattern mutations would be nice.
The logic is very different between these cases. Case 1: User requests A if user indicates they accept gzip encoding AND A.gz exists Return A.gz as A with an appropriate content-encoding header else return A Case 2: User requests A if A has a .svgz extension if user indicates they accept gzip encoding return A + content-encoding header else return an error code else return A While there are some common concepts, there is little/no overlap between these cases. I do not see a case for merging these use cases and maintain that handling of .svgz is best performed by a simple filter mapped to *.svgz until a more general solution (along the lines of https://java.net/jira/browse/SERVLET_SPEC-86) is provided by the container.
You're right in that the cases are different. I just wanted to point-out that related capabilities already exist in Tomcat. I think the right was to do this is to put a Filter in the examples webapp.
*** Bug 55943 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 55946 ***