<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Jonathan idea looks like a nice solution, because there is no modification of original nginx (good for updates and maintenance thus good for security).<br>

</div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">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).<br>

</div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br>However that means uncompressed traffic between backend and nginx proxy, thus:<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">

++ traffic volume (memory) in backend interface compared to frontend interface<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">-- CPU time on backend to compress data and on proxy to uncompress it<br>

<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">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.<br>

<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">My 2 cents,<br></div><div class="gmail_extra"><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font>
</div></div>