DevHeads.net

Urgent: Need to compress only above 1MB files in Apache webserver

Hello,

Do we have any option to compress only above 1MB size files in Apache 2.4?

Thanks & Regards

This e-mail message and any files transmitted with it may contain confidential and proprietary information and are intended solely for the use of the individual or entity to which they are addressed. Any unauthorized review, use, disclosure or distribution is strictly prohibited. If you have received this e-mail in error please notify the sender by reply email and destroy all copies of the original message. Thank you for your cooperation.

Comments

Re: Urgent: Need to compress only above 1MB files

By William A. Rowe Jr. at 01/10/2019 - 19:30

Compression on-the-fly is generally unwise. Incrementally better
compression comes at an escalating server cpu penalty. There might be some
way to trigger mod_deflate using mod_lua or mod_rewrite if you were
adventurous, but see this page for info about expr tests for filesize you
can use to toggle the no-brotli and no-gzip flags if you want to try
something straightforward; <a href="http://httpd.apache.org/docs/2.4/expr.html" title="http://httpd.apache.org/docs/2.4/expr.html">http://httpd.apache.org/docs/2.4/expr.html</a>

For static content, the right solution is to use mod_negotiation to
transparently serve either brotli or gzip files on the fly based on the end
users accept-encoding request header. It would be nonsense to compress all
such 1mb content on the fly, so instead you provision all three files
alongside one another. E.g. index.html.nc, index.html.gz and index.html.br
reside in the same directory, and the request comes in for index.html
triggering a search for the best match. Your provisioning scripts decide to
create (or update stale) .gz and .br copies of the content to serve
compressed. This wastes zero cpu resource serving the responses, and where
there are no .gz or .br compressed files, the single cleartext flavor will
be served.

This also means there is no compression of dynamic content, however, unless
it is served to the httpd gateway already compressed. Since there is no
file to fingerprint to decide if it is 1MB or smaller, dynamic content
can't be toggled as you've ask in your top post through a 'filesize'
mechanism. Given a response from the backend that has a Content-Length, it
could be finagled, but otherwise requires buffering all 1MB first to decide
if a Transfer-Encoding: chunked backend response is going to add up to 1MB
or not.

On Thu, Jan 10, 2019 at 4:00 PM Srikanth Pippari < ... at vitechinc dot com>
wrote: