Hello,
On Thu, Jun 9, 2011 at 4:27 AM, Pid <[email protected]> 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) +
DEFAULT_GZIP_FILE_EXTENSION) "" exists.
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()?
Thanks,
-Jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
