tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Farinacci <>
Subject Re: serving pre-compressed files
Date Thu, 09 Jun 2011 12:34:15 GMT

On Thu, Jun 9, 2011 at 4:27 AM, Pid <> wrote:
> Not quite the same, but similar, is the following:
> If you're using Tomcat 7, you have Servlet 3 compatibility, which means
> you can serve resources out of a specially* constructed jar.
> * Put resources in: myresource.jar:/META-INF/resources and they will
> appear as from the root of the webapp.
> e.g.  /META-INF/resources/logo.gif -> /logo.gif

That is pretty cool! Thanks for sharing that tip.

I did not find anything with tuckey urlrewrite, so I just wrote a
quick javax.servlet.Filter. It sanity checks: 1) no ?gzip=false
parameter (a la Tomcat's compression filter), and 2) Accept-Encoding:
{,x-}gzip in any of the headers, and 3)  that "" new
File(request.getContextPath().substring(1) +

On any FNFE / IOE, silently discard the exception and run the rest of
the chain; otherwise setting response header Content-Encoding: gzip
and copying the compressed version directly to the
response.outputStream before closing it.

It seems to work alright. My only concerns lay with: 1) malicious
contextPaths with ../../-style navigation, and 2) unpacked WARs which
contain the gzipped resource will take FNFE and not serve the
pre-compressed output as expected, and last and least 3) Accept-Range
is completely ignored.

For # 1: Is there some better way I should be obtaining the resource?
For # 2-3: Would it be better for me to just issue response.sendRedirect()?



There are 10 types of people in this world, those
that can read binary and those that can not.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message