On 09/06/2011 13:34, Jesse Farinacci wrote:
> Hello,
>
> On Thu, Jun 9, 2011 at 4:27 AM, Pid <p...@pidster.com> 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
