Recently I was looking into having my upstream server gzip content that is sent to nginx (which is acting as a reverse proxy) to reduce local bandwidth. However, I needed to decompress the response so nginx could do some manipulation, then obviously it would get re-compressed (typically with brotli) before sending out to the client.
After finding numerous posts saying that "that feature doesn't exist", then looking at the source of the gunzip module and finding the "TODO" saying the exact thing I was looking for, I managed to find this old post from 2013 where someone made a patch to do the exact thing needed: http://mailman.nginx.org/pipermail/nginx-devel/2013-January/003276.html It's only about 11 lines of code, attached is a newer patch I did against 1.17.4 since the gunzip source changed a bit. Basically the patch adds the option "gunzip_force on;" I do agree with the TODO comment in the source that having a way for other modules to request decompression would be great, but also having a configuration option (like this patch) is also a good feature. After implementing this patch, and configuring the upstream server to use gzip level 1 (figured maximize speed and minimize cpu usage), my local bandwidth usage between the two immediately dropped 80-85%, and I swear even the load levels dropped a hair, probably due to less networking overhead, despite the compressing & decompressing of content. I realize there is probably a mile-long TODO list for nginx features, but something so trivial like this patch has such a huge impact on network usage and I'm sure a better implementation would still only be a minimal code change. Just trying to give this a nudge so it's not forgotten, as I did come across quite a few posts online into how to do such a thing, so the demand is out there. Jason
002_force_gunzip.patch
Description: Binary data
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
