Hi Cris, > Excellent information. Thank you! > > Is there a way to create a split point where sendFile will handle files of > certain mime types (or all mime-types except for an exclusion list of mime > types) and/or of certain sizes while compression will handle files of other > mime-types and/or certain sizes? > > Both settings have a minimum file size that engages their mechanism but to > set up a division of labor I would think we would need all of > include/exclude and max/min for both sendfile() and compression. Again, I > could be missing something obvious by staring at the problem too long. > > @André and the rest of the listserv, In your opinions-- thinking about the > web site consumer's experience, and having to choose either send sendfile() > or compression-- is the juice worth the squeeze so-to-speak keeping > sendfile() and sending uncompressed files, or is the better choice to > enable compression at the expense of direct static file access and save > bandwidth? >
There may be a different aspect! Are you servicing the file on an SSL and login protected website? Then you should be aware of the BREACH attack http://breachattack.com/ and restrict the compressed resources wisely. Basically the authors say: do not use compression. Best regards Peter > > > > On Tue, Apr 18, 2017 at 9:08 AM, André Warnier (tomcat) <a...@ice-sa.com> > wrote: > > > On 18.04.2017 14:50, Chris Gamache wrote: > > > >> Using tomcat 8.0.43 ... > >> > >> I'm grappling with GZip compression options. Historically, I've used a > >> custom GZip filter and that's been fine for the most part. If the file > >> being served is under 50K the filter would compress it in memory and send > >> it out. If the file is over 50K, it would connect the OutputStream to a > >> GZipOutputStream rather than compressing the whole thing in memory and > >> then > >> sending it out from there. When that happens it doesn't send a > >> Content-Length header. This is fine for most browsers. Safari has a > >> problem > >> with this and will decline to receive the file. In looking at the GZip > >> filter I've been using, it's kind-of naive-- there must be a more > >> intelligent compression option built into tomcat by now, right? > >> > >> To enable compression, I set `compression="on"` in my <Connector/> element > >> in my server.xml file. There is on sticking point-- if sendFile is > >> available (asynchronous file-sending by the DefaultServlet using NIO) it > >> will trump compression by default. I can turn off sendFile, and browsers > >> report that they are receiving compressed files. So it seems like an > >> all-or-nothing situation where compression and sendFile are mutually > >> exclusive. There are minimum file size settings for both options, but no > >> max file size settings so I can't say "use sendFile for files under 50K > >> and > >> compression for files above 50K" because sendFile will always trump > >> compression. > >> > >> I think the idea of sending out static files asynchronously is fantastic. > >> I > >> also want my pages to load faster by sending less data. > >> > >> I figure the smart people who work on tomcat know a whole lot more about > >> this stuff than I do. They must have had a reason to prioritize sendFile > >> over compression, or the expert tomcat administrators have figured out a > >> way to balance the two. > >> > >> Maybe I've been staring at the problem too long, but I can't figure it > >> out. > >> > >> So, is it advisable turn of sendFile to engage compression? Or, is there a > >> combination of settings that will let me best use them both? > >> > >> > > For what it's worth : > > sendfile() is a way by which the (web) application can just point the OS > > to a static file on disk, and say "send this". And the sendfile logic in > > the OS takes care of the rest, in the most efficient way possible for that > > OS, and the call returns ok to your application right away, even possibly > > before the sendfile() action has completed. > > The sticky point here is "a static file on disk". > > So if you want to send back a gzipped file, then the only solution is to > > first create that gzipped version as a file on disk, and then use > > sendfile() on that gzipped version. > > And then, presumably, you'd want to "clean up" these gzipped versions at > > some point. > > Which cannot happen right after you have called sendfile(), because you do > > not really know when it will be done actually sending the file. > > So it is not really a "priority" issue, it is that these are different > > things, and that sendfile() really only works on a file, not on dynamic > > output from a webapp. > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > >
