Decompressing a compressed response from upstream, applying transformations and then compressing for

Server NGINX
1

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
2

Hello Maxim,

Would you suggest the code change to achieve this?

Thanks,
Makailol

3

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/

4

On 20 January 2014 14:34, Makailol C. [email protected] 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

5

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.