<html><head></head><body><div class="ydpfcd593d2yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div>
<div dir="ltr" data-setdir="false">Hello Maxim,</div><div dir="ltr" data-setdir="false">Thank you for this detailed answer.</div><div dir="ltr" data-setdir="false">I'll keep it in my personal notes.</div><div dir="ltr" data-setdir="false">I wish you a good year for 2023<br></div><div><br></div>
</div><div id="yahoo_quoted_3233523689" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
Le vendredi 30 décembre 2022 à 01:17:11 UTC+1, Maxim Dounin <mdounin@mdounin.ru> a écrit :
</div>
<div><br></div>
<div><br></div>
<div>Hello!<br><br>On Wed, Dec 28, 2022 at 11:05:01PM +0000, Mik J via nginx wrote:<br><br>> What is the best practice for these two situations:<br>> 1. Compress text files, should I make the compression on the <br>> reverse proxy or on the backend server ?<br><br>In most cases, it makes sense to compress things on the frontend <br>server.<br><br>In particular, this is because of at least the following factors:<br><br>1) Frontend servers are usually not just reverse proxies, but also <br>serve some static resources. As such, compression is anyway needs <br>to be configured on frontend servers.<br><br>2) Frontend servers often used with multiple different backends. <br>Further, in some cases they are used to generate responses based <br>on subrequests to different requests, such as with SSI. This <br>makes compression on frontend servers easier or even the only <br>possible solution.<br><br>3) Frontend servers are often used to cache backend responses, and <br>proper caching of compressed responses might be problematic and/or <br>inefficient (in particular, because the only mechanism available <br>is Vary).<br><br>Note well that by default nginx uses HTTP/1.0 when connecting to <br>upstream servers, and this in turn will disable gzip with default <br>settings. This naturally results in compression being done on <br>frontend servers when nginx with default settings is used both as <br>a backend and a frontend.<br><br>In some cases, it might make sense to compress on the backend <br>servers, for example, to ensure that CPU usage for compression is <br>balanced among multiple backend servers, or to minimize traffic <br>between frontends and backends. These are mostly about specific <br>configurations though.<br><br>> 2. Deny access to specific files for example, files starting <br>> with a dot .file, should I write the rule on the reverse proxy <br>> or on the backend server ?<br><br>I would recommend both. In particular, rules on the backend <br>server will ensure that the access is denied where the file <br>resides, making things safe even if the frontend servers is <br>somehow bypassed. Rules on the frontend server ensure that <br>requests are denied efficiently.<br><br>-- <br>Maxim Dounin<br><a href="http://mdounin.ru/" target="_blank">http://mdounin.ru/</a><br>_______________________________________________<br>nginx mailing list<br><a ymailto="mailto:nginx@nginx.org" href="mailto:nginx@nginx.org">nginx@nginx.org</a><br><a href="https://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">https://mailman.nginx.org/mailman/listinfo/nginx</a><br></div>
</div>
</div></body></html>