<div dir="ltr">This seems intentional, per the documentation at <a href="http://nginx.org/en/docs/http/ngx_http_gzip_static_module.html">http://nginx.org/en/docs/http/ngx_http_gzip_static_module.html</a>:<div><br></div><div>"The following directives are also taken into account: gzip_http_version, gzip_proxied, gzip_disable, and gzip_vary."</div><div><br></div><div>No mention of gzip_types. I recommend only enabling gzip_static in a location block where you know you have pre-compressed assets present.</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 24, 2018 at 12:55 PM Matt Gadient <<a href="mailto:jdi_knght@hotmail.com">jdi_knght@hotmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've noticed for a while that when gzip_static is enabled it checks *every* file it serves for a .gz extension, not just the ones listed in the gzip_types. For example in a page with 1 html and 30 images you'll have 61 requests to the file system: 1 for the correct .html.gz file, 30 for the non-existent .png.gz files, and 30 for the .png files.<br>
<br>
You can verify this on a running server that has gzip_static on, with "strace -p PID 2>&1 | grep gz" (where PID is an nginx worker's PID). Visit a page of the site that has images and you'll get a whole bunch of "-1 ENOENT (No such file or directory)" in the output attached to /var/www/website/image.png.gz files.<br>
<br>
I am wondering if this is intentional or if it is a bug. Thanks for your time.<br>
<br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</blockquote></div></div>