-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
I'll be a little more detailed than Jason's response... On 5/20/2010 4:04 PM, André Warnier wrote: > The question is : > Suppose that to gain space on my Tomcat server and to speed up content > delivery, I have a whole bunch of files in one of my Tomcat contexts, > which have been pre-zipped. The client isn't going to unzip your file for you unless it's been configured to present a "what do I do with this file?" dialog and an appropriate uncompressor is installed. If you switch to a different kind of compression, say, gzip, then you can maybe get what you want. If you're looking for "on-the-fly transfer compression" without all the time wasted for that "on the fly" part (because you're using static files), then you can use a 'gzip' content-encoding which is specified in the (duh) HTTP spec. > That is, I have for example a.txt, b.txt, c.txt etc... but all these > huge text files have already been pre-zipped, and they are really on my > server as > (catalina_base)/webapps/mywebapp/ > a.txt.zip > b.txt.zip > c.txt.zip > etc... > > Now I would like the user to be able to request the URL > http://hostname/mywebapp/a.txt > and obtain this file, as a text, displayed in the browser window. What I've described above sounds like it will meet your requirements. I think you can do this with (what else?) a filter that: 1. Checks the URL to see if it's one of the "special" paths that has been pre-zipped (an exercise for the reader) 2. Checks the accept-encoding header from the client to see if accepts the type (or types!) of compression you have pre-arranged 3. Intercepts the request, /does not call chain.filter()/, and instead: a. Sets the Content-Encoding header to 'gzip' (or whatever, see: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5) b. Serves the bytes from the pre-compressed file c. Properly handles the Content-Length header. You'll have to comb the spec to find out of the Content-Length should be the size of the compressed file (probably) or the size of the file when uncompressed (probably /not/) This filter will allow you have your cake and eat it, too, so to speak: you get the benefit of pre-compressed files (no CPU time spent on on-the-fly compression) and the ease of using the HTTP spec which generally provides for the transfer of gzip-compressed files that are expected to be auto-expanded by the /user agent/, not a helper program like WinZip or whatever. > And I also do not want to leave my files on disk as a.txt, b.txt, etc.. > and ask Tomcat to compress them on-the-fly just before sending them to > the browser. The files are already compressed, so that would be a waste > of CPU cycles. Agreed. You'll want to leave the .txt files there, anyway, just in case the client doesn't support gzip compression (as advertised in the Accept-Encoding request header). > (If it makes it easier to conceive the difference or benefit, you can > also think that instead of text files, these are originally very large > PDF files (say a.pdf), which have been zipped (as a.pdf.zip), but which > I want to display as PDF in the browser (as a.pdf)) Technically speaking, isn't PDF already LZ compressed? > I can think of creating a special servlet that would do that, by playing > with the Content-transfer-encoding header. > But considering that the default servlet must be already doing more than > that (when it actually compresses content before returning it), and is > probably much better written and optimised than what I could come up > with myself, isn't there a smarter way to do this without writing a > special servlet to do it ? I wonder if a patch could be written for the DefaultServlet to do something like this: if compression has been enabled on the <Connector>, the request is for file "foo", and "foo.gz" exists in the same location, use the "foo.gz" file as source instead of compressing on the fly. On the other hand, perhaps the DefaultServlet caches its compressed files and you're not saving yourself much with this extra complexity. Someone more familiar with the intracacies of DefaultServlet will have to enlighten us. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv1pSoACgkQ9CaO5/Lv0PC+bgCcC3uWm0Ii8ICj4KSrzbaTQV8S gL4AoIYhBhEKueZeVvU6IiqSDtMJsjhe =FLdB -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
