On 09/06/2011 13:34, Jesse Farinacci wrote: > 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.
You don't need to use the File object:
ServletContext.getResourceAsStream("/path/to/resource.ext")
which has the additional benefit that the container should prevent
access to resources outside of the context, as the path is relative to
the context.
p
> 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
>
signature.asc
Description: OpenPGP digital signature
