tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: serving pre-compressed files
Date Thu, 09 Jun 2011 16:22:20 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jesse,

On 6/9/2011 8:34 AM, Jesse Farinacci wrote:
> 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 might want to check out how Apache httpd does the same type of
thing. It uses the "Vary" response header which may be a bit more polite.

> 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.

You shouldn't have to catch any exceptions. The java.io.File constructor
won't throw an exception with a non-existent path, and you can call
File.exists to check if it exists. That might simplify your code, too.

> It seems to work alright. My only concerns lay with: 1) malicious
> contextPaths with ../../-style navigation

You can normalize the path and then check to see where it lives.

Note that by using java.io.File you are both circumventing the
container's protections against filesystem protection /and/ requiring
that your files actually be on a filesystem.

Instead, you might want to try something like
ServletContext.getResource() to see if it's null, and then forwarding to
it using the request dispatcher if it's not null.

> 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.

If you use the request dispatcher, Accept-Range might be handled for you
by the DefaultServlet.

> 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()?

It depends upon the size of the file. An HTTP request is not free,
especially over SSL. If the size of the response will be small, you may
as well do the work on the server during the first request, instead of
forcing the client to make a second request.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3w8zwACgkQ9CaO5/Lv0PBcCwCgp2J8laDq5SaBLF0HNWaxHHJs
IrIAn0vOwZJ1QnmTrSTBJwFCZvd8FKrn
=quWt
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message