# Decompressing a compressed response from upstream, applying transformations and then compressing for **URL:** \ **Category:** NGINX\ **Created:** [January 20, 2014, 2:41pm UTC](https://www.ruby-forum.com/t/decompressing-a-compressed-response-from-upstream-applying-transformations-and-then-compressing-for/238612 "2014-01-20T14:41:28Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\ **Post date:** [January 20, 2014, 2:41pm UTC](https://www.ruby-forum.com/t/decompressing-a-compressed-response-from-upstream-applying-transformations-and-then-compressing-for/238612/1 "2014-01-20T14:41:28Z")
Hello Is there a way we can achieve the following when nginx is acting as a reverse proxy 1. Client sends HTTP request with Accept-Encoding as gzip 2. Nginx proxy forwards the request with the request header intact 3. Origin server sends a compressed response 4. At the nginx proxy, we _decompress_ the response, apply transformations on the response body and then _again_ compress it In other words, is there a way to use the functionality of gzip and gunzip modules simultaneously for a processing a response and in a particular order ---
**Author:** ![Rv\_Rv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c0e974/32.png) [@Rv\_Rv](https://www.ruby-forum.com/u/Rv_Rv)\ **Post date:** [January 20, 2014, 3:35pm UTC](https://www.ruby-forum.com/t/decompressing-a-compressed-response-from-upstream-applying-transformations-and-then-compressing-for/238612/2 "2014-01-20T15:35:38Z")
Hello Maxim, Would you suggest the code change to achieve this? Thanks, Makailol ---
**Author:** ![Rv\_Rv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c0e974/32.png) [@Rv\_Rv](https://www.ruby-forum.com/u/Rv_Rv)\ **Post date:** [January 20, 2014, 2:49pm UTC](https://www.ruby-forum.com/t/decompressing-a-compressed-response-from-upstream-applying-transformations-and-then-compressing-for/238612/3 "2014-01-20T14:49:28Z")
Hello! On Mon, Jan 20, 2014 at 09:40:30PM +0800, Rv Rv wrote: > In other words, is there a way to use the functionality of gzip > and gunzip modules simultaneously for a processing a response > and in a particular order As of now, it’s not possible without code modifications - mostly because there is no way to tell gunzip filter you want it to always decompress a response. It can be achieved with minor code changes though. – Maxim D. [http://nginx.org/](http://nginx.org/) ---
**Author:** ![Rv\_Rv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c0e974/32.png) [@Rv\_Rv](https://www.ruby-forum.com/u/Rv_Rv)\ **Post date:** [January 20, 2014, 3:51pm UTC](https://www.ruby-forum.com/t/decompressing-a-compressed-response-from-upstream-applying-transformations-and-then-compressing-for/238612/4 "2014-01-20T15:51:44Z")
On 20 January 2014 14:34, Makailol C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Hello Maxim, > > Would you suggest the code change to achieve this? Instead of forking your own incompatible nginx version, I’d be tempted to test this out: Turn gzip on. Always remove the Accept-Encoding header from the proxied request. Perform the transformations on the uncompressed response. Let nginx gzip the content on the way back to the client. The ordering of the different modules you’re using may spoil this idea, of course, but I’d give it a go myself. Cheers, Jonathan ---
**Author:** ![Rv\_Rv](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/c0e974/32.png) [@Rv\_Rv](https://www.ruby-forum.com/u/Rv_Rv)\ **Post date:** [January 20, 2014, 6:44pm UTC](https://www.ruby-forum.com/t/decompressing-a-compressed-response-from-upstream-applying-transformations-and-then-compressing-for/238612/5 "2014-01-20T18:44:27Z")
Jonathan idea looks like a nice solution, because there is no modification of original nginx (good for updates and maintenance thus good for security). Always avoid breaking the update chain (thus diverting from original source, unless having another repository being reactive to - security - updates which you could pull from). However that means uncompressed traffic between backend and nginx proxy, thus: ++ traffic volume (memory) in backend interface compared to frontend interface – CPU time on backend to compress data and on proxy to uncompress it Depending on your application, that could create a bottleneck. Maybe caching the compressed result on the proxy would help reducing backend work and traffic and as a result hope to limit the burden to it. ## My 2 cents, _B. R._